Integrating Focus FCU Mobile — an Oklahoma credit-union app that already aggregates outside accounts

The thing worth integrating

What makes Focus FCU Mobile interesting to an integrator is not the standard credit-union feature set — balances, transfers, bill pay, mobile remote deposit — but the cross-FI aggregation Focus has wired into the member experience, where one login surfaces accounts the member also holds at other banks and credit unions. The app describes this as letting a member "aggregate all of your financial accounts… into a single view," per its Play Store listing. For anyone building a personal-finance dashboard, a small-business cash-position view, or a household ledger for an Oklahoma member, that aggregated tree is what you actually want — not just the Focus share account in isolation.

Focus FCU Mobile is the member front-end for The Focus Federal Credit Union, headquartered in Oklahoma City and serving members since 1955 per the institution's own site. The integration question is therefore narrow and concrete: how do you get the same per-member view the app shows, on a schedule, into your own system, with a paper trail your compliance reviewer will accept.

Member-side data the integration actually reaches

How we'd actually reach it

Member-authorized portal integration

The dependable path. With the member's own consent we authenticate as them against the Internet Banking session the app uses, walk MFA, and read the same surfaces the app reads. Effort is medium — the credential and session flow is the part most worth getting right. Durability is good for as long as the member keeps the consent valid; we wire a session-health probe so the integration declares itself broken rather than returning stale zeros. Onboarding the member consent flow is part of the build, not a precondition we hand back to you.

Protocol analysis of the app's own traffic

For the aggregated outside-account rows specifically. The app talks to a credit-union banking back end and that back end talks to an aggregator; the aggregate view is rendered server-side. We reverse the request/response contract for the aggregate panel under the member's authorization so the integration can read the same JSON the app receives, rather than re-aggregating ourselves and double-spending the consent. Effort is the highest of the routes; the durability tradeoff is that a vendor-side change to the panel format triggers our re-validation pass.

FDX-aligned consumer-permissioned access (where it lands)

The credit union sector is moving toward FDX-aligned access via the aggregators the member already trusts (Plaid, MX, Finicity), and the studio can wire to whichever aggregator path the credit union exposes when one becomes available for a given Focus member. We treat this as a parallel route, not the only one — the route that actually delivers today is member-authorized portal integration; FDX-aligned access becomes the spine when the institution exposes it.

Native member export

Statements and transaction lists are exportable by the member from the portal (PDF and CSV). It is the fallback we keep available for one-off historical pulls, not a basis for an ongoing sync.

In practice, member-authorized portal integration does the actual heavy lifting today. We add the protocol-analysis read of the aggregate panel only when the household-view rows are genuinely wanted, and we keep the FDX-aligned path queued so it can take over later without your code changing shape, if and when the institution exposes it for a given Focus member.

What lands in your repo

• OpenAPI 3.1 spec describing the per-member endpoints we expose to you: accounts, balances, transactions, statements, transfers, deposits, alerts, card-state, and the separately-flagged aggregated-external feed.
• A protocol & auth-flow report covering Internet Banking login, MFA challenge handling, session-token refresh, the credential-rotation hook, and the consent log schema.
• Runnable source for the integration in Python and Node.js — the same surfaces, with retry, backoff, and explicit session-health probes wired in.
• Automated tests against a member-consented test account: balance read, transaction page-through, statement fetch, transfer scheduling, deposit-status read, alert-rule round-trip, and a deliberate session-expired test that asserts the integration surfaces the re-consent event rather than returning silent zeros.
• Interface documentation a teammate can actually onboard from — the schema, the call contracts, the rate-limit assumptions, and the "what to do when the portal front end changes" runbook.
• Compliance & data-retention guidance: consent log format, default retention windows (deposit images held only as long as the workflow needs them, transaction text held per your policy), NDA, and the audit-trail export.

Call-shape sketch (illustrative)

This is the shape we expose to your code, not a vendor contract; exact field names are confirmed during the build against the live Focus member portal under member authorization.

POST /v1/session/login
{ "member_login": "<internet-banking-username>",
  "credential":   "<password>",
  "device_trust": "<optional registered-device token>" }
→ { "session": "...", "mfa": { "required": true, "channel": "sms|app|email" } }

POST /v1/session/mfa
{ "session": "...", "code": "######" }
→ { "session": "...", "expires_in": 900,
       "consent_id": "...",   // written to the append-only consent log
       "scopes": ["balances","transactions","statements","deposits","cards"] }

GET /v1/accounts
Authorization: Bearer <session>
→ {
    "internal": [
      { "id": "FOCUS-...", "type": "share|share_draft|loan",
        "balance": "...", "available": "...", "currency": "USD",
        "as_of": "2026-05-26T14:02:11Z", "source": "focus_native" }
    ],
    "aggregated_external": [
      { "id": "EXT-...", "institution_label": "...",
        "type": "checking|savings|card", "balance": "...",
        "as_of": "...", "freshness_seconds": 86400,
        "source": "aggregator_relayed",     // never confused with focus_native
        "trust": "lower" }
    ]
  }

GET /v1/accounts/{id}/transactions?from=YYYY-MM-DD&to=YYYY-MM-DD&cursor=...
→ paged list { date, amount, status: "posted|pending",
                  description, member_tag?, member_note?, receipt_image_url? }

GET /v1/deposits?from=YYYY-MM-DD
→ [ { id, date, amount, status: "posted|held|rejected",
         hold_release_date?, image_on_demand: "/v1/deposits/{id}/image" } ]

POST /v1/session/refresh   → rotates session token, no re-MFA inside window
POST /v1/session/revoke    → writes a close event to the consent log

The session-health probe runs as a separate cron call; on a 401 from the portal it writes a re-consent event into your queue with the member identifier and the scopes that were active, so your member-facing notification can ask them to re-authorize cleanly.

What the build accounts for, specifically for Focus

• The aggregate rows are a different trust tier. Focus-native shares and drafts come straight from the credit union core; the externally aggregated rows are relayed through whichever aggregator the credit union has wired in. We mark every row with source: focus_native vs source: aggregator_relayed and a freshness_seconds field so a downstream dashboard can decide on its own whether to show, dim, or refuse a stale aggregator reading.
• Internet Banking is the sole credential path. The app explicitly requires the member to already be enrolled in Focus Federal Internet Banking and to log in with the same credentials. We design the consent flow around that — one credential, one consent record, one revocation surface — and we handle the device-trust enrollment as part of onboarding so the integration does not get challenged every run.
• Member-added metadata is real data. The app lets members attach tags, notes, and receipt photos to transactions. That metadata is genuinely useful for downstream classification, and we pull it; we also keep it in its own table so a future privacy review can drop it without touching the canonical transaction stream.
• RDC images are kept on-demand. Cheque images for mobile remote deposit are large, sensitive, and largely uninteresting after the deposit posts. We pull them lazily, hold them only for the window your workflow needs, and let the integration default to metadata-only.
• Front-end churn is treated as a normal event. The credit-union digital-banking layer changes on a vendor's release cadence, not ours. We hand over a contract-test suite that re-runs against the live portal on a schedule you control, so a panel-format change shows up as one failing assertion with a diff, not as a slow corruption of the data feed.

Authorization, and the §1033 question for credit unions

The dependable basis for this integration today is the Focus member's own authorization, recorded in the consent log described above, with scopes the member can read back and revoke. The Focus Federal Credit Union is federally chartered and federally insured per its CreditUnions.org listing; member data sits under the credit union's existing privacy obligations and the NCUA's supervisory frame, with member consent as the operative permission for a third party to read it.

The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is where this is supposed to be heading and is not, as of this writing, in force: the rule was finalized in October 2024, then enjoined and stayed in Forcht Bank v. CFPB in October 2025, and the Bureau is reconsidering it through an Advance Notice of Proposed Rulemaking published August 22, 2025 (Federal Register). Any reading of §1033 as the present-tense framework that "governs" credit-union open banking, or as a settled phased-by-asset-size obligation, is wrong for 2026; the page is therefore explicit that the integration rides member consent now, and the §1033 path is a forward-looking option to swap into once the reconsideration lands.

In practical terms: NDA on request, data minimization by default, append-only consent log, scoped revocation, and no storage of credentials in the deliverable beyond what the runtime needs in memory for a session.

Member-portal surfaces (Play Store screenshots)

Other credit-union member portals integrators tend to ask about next

Same shape of integration question, different institution. Listed for ecosystem context, not ranked.

• First Oklahoma FCU — Oklahoma-based member portal with standard balance, transfer, and remote-deposit surfaces.
• Communication Federal Credit Union — Oklahoma and Kansas member base; comparable share-draft and card-control surfaces.
• Community Focus FCU Mobile — separate institution sharing the name shape; member-portal data behind a similar Internet Banking login.
• OK Members First Federal Credit Union (OK Members FFCU) — small-FI member app with the typical balances/transfers/deposit set.
• Tinker Federal Credit Union — large Oklahoma credit union; richer member-portal data and a wider product mix.
• Allegiance Credit Union — Oklahoma City; member portal with the same household-finance surfaces.
• WEOKIE Federal Credit Union — Oklahoma City; member-side data behind Internet Banking credentials.
• True Sky Credit Union — Oklahoma City; comparable feature set for an integrator pulling a household view.
• Oklahoma's Credit Union (OECU) — statewide membership; standard mobile-banking domains.

Questions Focus integrators usually ask first

Can the integration pull the external accounts a Focus member already linked, or only the internal Focus shares and drafts?

Both, but with different durability. Internal Focus shares and drafts come straight from the member's portal session and are the cleanest surface. The externally aggregated rows come from whichever aggregator the credit union has wired in behind the scenes; we treat those as a separate, lower-trust feed in the schema so a downstream consumer can tell apart a Focus-native balance from a third-party-relayed one.

If a Focus member rotates their Internet Banking password, does the integration silently break?

It would, if we left it that way. The build includes a credential-rotation hook and a session-health probe so a rotated password surfaces as an explicit re-consent event in your queue, not as a silent zero-balance read. Members are notified through the same channel they used to authorize the integration.

Does the integration include mobile remote deposit captures the member submitted from the app, and at what granularity?

Deposit metadata yes — the date, amount, posting status, and the cleared/held split. The cheque images themselves are only retrieved on demand and held only as long as you actually need them, so the integration does not turn into a member-cheque archive by accident.

How is the consent recorded so an auditor can see who authorized what, when, and for which scopes?

Every consent event is written to an append-only log with the member identifier, the scopes granted (balances, transactions, statements, deposits, card metadata), the timestamp, the source IP, and the expiry. Revocation writes a matching close event. The studio hands over the schema and a CSV/SQL exporter so the same log feeds your audit and complaint workflows.

What we checked, and when

This mapping was produced from the institution's own published material and the public regulatory record: the Focus FCU mobile-banking page describing the feature set; the Play Store listing for the package com.focusok.grip and its description of cross-institution aggregation; the institution's directory listing for charter and routing details; and the current CFPB record on the Personal Financial Data Rights rule, including the August 2025 reconsideration notice.

• Focus FCU — Mobile Banking (focusok.com)
• Focus FCU Mobile on Google Play (com.focusok.grip)
• Personal Financial Data Rights Reconsideration — Federal Register, 22 Aug 2025
• CFPB — Personal Financial Data Rights Reconsideration page

Mapping reviewed at the OpenBanking Studio integration desk, May 2026.

How an engagement runs

For Focus FCU Mobile specifically, what you brief us with is the app name and what you need from its data — a member-balance feed, a household ledger, a deposit-status webhook, a household net-worth view, or a CSV-grade reconciliation pull — and we come back with the route, the schema, and a one-to-two-week build window. Access setup (member consent flow, sandbox or consenting test member, NDA where you want one) is arranged with you during onboarding, not a list of things you need to clear before we start.

Source-code delivery starts at $300 and is paid only after we hand over runnable source plus the OpenAPI and auth-flow spec and you are satisfied it does what you asked for. If you would rather not run the integration yourself, the same surfaces are also available as a hosted endpoint you call on demand — no upfront fee, billed per call. Either path runs on a one-to-two-week build cycle. Send the app name and the requirement to /contact.html and we will come back with the route we would take for this specific Focus member surface.