Reaching Southwest Financial member accounts through the Malauzai portal

Southwest Financial Federal Credit Union — Kro-Dal of Dallas at the start, now Farmers Branch — runs about 8,700 members and a roughly $85M balance sheet through a Malauzai-built mobile app and a separate online banking portal at onlinebanking.swfinancial.org. Membership is the Kroger associate base plus several hundred Select Employee Groups, so the data behind any one login is whatever shares, loans, cards, Zelle activity and SavvyMoney score that one member has on file. The shortest authorized path to that data is the member's own consent, which is what the rest of this page is about.

Routes into the account data

There are a few credible ways to reach a single SFFCU member's records, and the recommendation depends on what the customer actually needs.

1. Member-consented credential integration (recommended)

The Malauzai client and the portal share the same back end. We replay that auth flow under the member's authorization — bootstrap, credential post, MFA challenge, session — and then pull balances, history and statement metadata against the same internal endpoints the SmartApp uses. Effort is one to two weeks of setup and a maintenance line for version churn. Durability is good as long as the contract tests catch field renames before users see them.

2. Protocol-analysis-led capture

Where the customer would rather not store member credentials at all, we capture the Malauzai device-bound flow (device-id cookie, refreshable token) once during onboarding, hand it back to the member, and reuse the session token under their control. Effort is similar; durability hinges on the token lifetime, which we document at the end of the build.

3. SavvyMoney partner endpoints

The credit-score panel inside the SFFCU app is not native — it's a SavvyMoney SSO embed with a REST surface (User Status and User Credit Score). For score, rating, monitoring flags and last-pull date, that surface is the right entry point; we wire it in parallel and join the result on member id.

4. Statement export as fallback

The portal ships a periodic PDF/CSV statement export. It's worth wiring as an audit trail even when route 1 is the spine — easy to diff against, easy to hand to compliance.

For most customers the answer is route 1 as the primary read, SavvyMoney bolted on for score data, and a recurring statement export pulled into the same bucket for reconciliation.

What the portal actually surfaces

A look at the auth flow

The Malauzai client funnels every read through a session cookie and a device-id pair. The shape below is illustrative; the exact field names and CSRF mechanism are captured during the build, and we pin them in a contract-test file.

import requests

BASE = "https://onlinebanking.swfinancial.org"
session = requests.Session()

# 1. bootstrap the Malauzai login form — captures CSRF + a device fingerprint cookie
r = session.get(f"{BASE}/login", headers={"User-Agent": UA})
csrf = parse_csrf(r.text)

# 2. submit member credentials -> session cookie + (usually) an MFA challenge
r = session.post(f"{BASE}/auth", data={
    "username": MEMBER_LOGIN,
    "password": MEMBER_PASS,
    "csrf":     csrf,
    "device_id": DEVICE_ID,         # tied to the consenting member at onboarding
}, allow_redirects=False)

# 3. handle MFA out-of-band — SMS or push to the member; push the OTP back
if r.status_code == 401 and r.json().get("mfa_required"):
    code = wait_for_member_otp()
    session.post(f"{BASE}/auth/mfa", data={"code": code, "csrf": csrf})

# 4. list shares (savings, Mighty Maxx, loan, card) — the same JSON the SmartApp reads
shares = session.get(f"{BASE}/api/v1/accounts").json()

# 5. ninety days of activity per share, paginated where the feed is long
for s in shares["accounts"]:
    txns = session.get(
        f"{BASE}/api/v1/accounts/{s['id']}/history",
        params={"start": "2026-02-28", "end": "2026-05-29"},
    ).json()
    yield normalize(s, txns["items"])      # -> unified record (see below)

Errors and quirks worth knowing up front: the device-id cookie is short-lived on first install and longer-lived after a successful MFA loop; a forced password reset (the portal periodically nags members) invalidates the session mid-pull; and the activity feed paginates differently on the SmartApp than on the desktop portal, so the page sizes line up only if you ask explicitly.

Normalized record we hand back

Every read comes out in one shape no matter which route fed it, so downstream code touches one schema:

{
  "account_id": "sffcu:share:7421",
  "kind": "savings",            // savings | checking | loan | credit_card
  "label": "Mighty Maxx Savings",
  "balance": {
    "current":   1240.18,
    "available": 1180.18,
    "currency":  "USD"
  },
  "transactions": [
    {
      "id":           "sffcu:tx:2026-05-22:9c2",
      "ts":           "2026-05-22T14:31:00Z",
      "amount":       -42.50,
      "kind":         "zelle_out",
      "counterparty": "TOKEN_LACQUER",
      "memo":         "rent split",
      "status":       "settled"
    }
  ],
  "credit_score": {              // joined from SavvyMoney, optional
    "value":  712,
    "rating": "good",
    "as_of":  "2026-05-25"
  }
}

What the build hands over

For an SFFCU engagement, the studio ships:

• An OpenAPI 3.1 spec covering the auth flow, accounts, history, statement export and the SavvyMoney join — versioned and shipped in-repo.
• A protocol and auth-flow report: bootstrap, login, MFA, refresh, session lifetime, the device-id pairing, and the field-rename log we built up during capture.
• Runnable source for the key endpoints in Python and Node.js — one tested call per row in the domains table above.
• An automated contract-test suite (pytest + a Node equivalent) that runs against a consenting test account on a cron, so a Finastra-side rename pages the on-call before it pages the customer.
• Interface documentation written for a developer who has never touched Malauzai before — quirks, the password-rotation trap, the desktop-vs-SmartApp pagination split.
• Compliance and retention guidance: consent records, scope, expiry, encryption at rest, revocation path.

If the engagement is the pay-per-call hosted form, the same surface ships as endpoints under our domain and you skip the runnable-source piece.

Things the studio plans around

A few app-specific facts that shape how the build is wired, all of which the studio handles as part of the engagement rather than asking the customer to handle first:

• Malauzai versioning is the main source of drift. The SmartApp gets back-end updates from Finastra; we pin the captured request shape, ship contract tests against a consenting test account, and the studio re-runs the capture when the portal front end ships a new build. Maintenance after delivery is part of how the pipe stays up.
• SavvyMoney is its own integration. The credit-score panel is an iframe with an SSO handshake, not a native field. We wire the User Status and User Credit Score calls in parallel and join the result onto the same per-member record so the downstream sees one feed, not two.
• Locator data is network data, not member data. The branch and ATM finder is the CO-OP / Velera and Allpoint network locator. If the customer needs it inside the integration we wire it as a separate, unauthenticated read so member consent stays narrowed to the financial reads.
• SEG variance is real. Membership runs from the original Kroger associate base through several hundred Select Employee Groups, and product eligibility differs by employer. We tag each member's eligibility once at link time so loan-product queries don't return offers a member can't act on.

Consent and the US picture

The right we build on for SFFCU is the member's own. They authorize the studio to read their portal data on their behalf, the consent is logged with explicit scope and expiry, and we hold the credential the way we'd hold any short-lived access token: encrypted at rest, narrowed to read-only endpoints, revocable from a page the member can reach. NDA at the project level, data minimization at the pipe level. The federal frame people will point to in the US is the CFPB's Personal Financial Data Rights rule (12 CFR Part 1033), but as of 2026 the rule is enjoined and back in agency reconsideration — see the CFPB's own reconsideration page — so it isn't a present-tense compliance anchor for anyone. State privacy laws plus GLBA on the financial side are what actually shape day-to-day handling today, and that's what the documentation we hand over reflects.

How this was put together

The picture above came from reading SFFCU's own public pages (About, Mighty Maxx, Maxx Money Manager, online banking landing), the Google Play and App Store listings for com.malauzai.SFFCU, the public record on Finastra's 2018 acquisition of Malauzai and the Fusion Digital Banking product page, SavvyMoney's mobile integration guide, and the current status of CFPB §1033 reconsideration. Member counts and the $84.9M asset figure are from SFFCU's About page as written; we have not independently audited them. Exact endpoint paths, field names, MFA behaviour and session lifetime are confirmed during the build against a consenting test account, not asserted here.

OpenBanking Studio · integration desk, 2026-05-29.

Adjacent apps in the integration picture

Reasonable comparators when you are looking at how member-portal integration is done for small US credit unions — relevant because the same Malauzai-or-similar pattern shows up across most of them:

• KEMBA Financial Credit Union — Central Ohio Kroger-rooted credit union; same Kroger-employee heritage as SFFCU, a comparable account list and member portal behind a Digital Banking app.
• KEMBA Cincinnati Credit Union — separate Kroger-employee credit union, online and mobile banking with transfers, cleared-check tracking and debit/credit card activity.
• KEMBA Louisville Credit Union — Kentucky Kroger-employee credit union, similar product mix and similar member portal surface.
• KEMBA Delta Federal Credit Union — smaller Kroger-employee credit union with a member portal of comparable scope.
• Southwest Research Center FCU — name-adjacent but unrelated; San Antonio-based, ~$70M, similar shared-branch and ATM-network posture.
• Credit Union of Southern California (CU SoCal) — Zelle plus mobile check deposit in a single mobile app; comparable consent surface.
• Partners Federal Credit Union — mobile check deposit and Zelle through the member app, similar member-consented read shape.
• USC Credit Union — Zelle inside the mobile banking app for in-and-out P2P, useful as a Zelle-history comparator.
• Credit Union 1 — Zelle and full digital banking, mid-size US credit union with a comparable member portal.
• Credit Union ONE — Michigan-based credit union with Zelle inside its mobile and online banking.

Same playbook applies to each: capture the authorized auth flow, treat third-party embeds (SavvyMoney, Zelle, locator) as separate integrations, and normalize into one record on the way out.

Questions integrators ask first

Will the SFFCU endpoints break if Finastra rolls a new Malauzai version?

A version bump is the most common cause of drift in this kind of pipe. We pin the request shape and the cookie or token chain we captured, ship a contract-test suite that runs nightly against a consenting test account, and the studio re-runs the capture when a field rename or CSRF detail changes. Maintenance is part of the engagement.

Can you pull the SavvyMoney credit-score widget data alongside the account data?

SavvyMoney is a separate surface. The score, score rating, monitoring alerts and last-pull date come back through its User Status and User Credit Score endpoints once SFFCU's SavvyMoney partner credentials are in our hands. We treat it as a second integration in the same project and fold the result into the same per-member record alongside balances and transactions.

What about Zelle activity — can history come back too?

Zelle activity shows inside the SFFCU portal as a payment line with timestamp, counter-party token, memo and final status, exactly the way the app surfaces it. We map those lines into the normal transaction stream so a downstream system sees a unified history rather than two parallel feeds.

Are shared-branch and surcharge-free ATM locations part of the pull?

That data isn't member-scoped — it lives in the CO-OP and Allpoint network locators (the same source the in-app branch and ATM finder uses). If the customer needs it inside the integration we wire it as a second read against the network locator rather than treating it as account data, so member consent stays narrowed to the financial reads.

Interface evidence

Public screenshots from the SFFCU listing — click to enlarge:

If you need this built

A source-code delivery for an SFFCU integration starts at $300 — runnable Python and Node clients, the OpenAPI spec, contract tests, and the protocol report — paid only after we ship and you've run it against your own member account. The alternative is the hosted form: call our endpoints and pay per call, nothing up front. Either way the cycle is one to two weeks from kickoff. Send us the app name and the data you actually need at /contact.html and we'll come back with a scoped build plan.

Mapping reviewed 2026-05-29.