Southland CU member accounts, integrated under member consent

Behind a single Southland Credit Union member login sit checking and share balances, a dated posted-transaction ledger, scheduled and past bill payments, Zelle activity, mobile-deposit history, a free FICO score, and — since the July 2022 NYDIG launch — a custodial bitcoin sub-account. That is a lot of structured per-member state in one place, and most of it never reaches a member's other tools. The integration question for Southland is not what is there. It is how to reach it without breaking the member's session or their consent.

The bottom line: this is a credit-union app with a wide authenticated surface and no single tidy export that covers all of it. A consumer-permissioned aggregation layer carries the common fields well; the rails an aggregator tends to thin out — pending Zelle, the bill-pay calendar, the NYDIG holdings, the FICO pull — are where authorized session-level integration earns its place. We would build the aggregation route as the backbone and bolt the session route onto the gaps.

Member data the Southland app holds

Each row is a surface a member actually sees in the app, mapped to what an integrator does with it.

Routes to Southland member data

Three routes apply here, in descending order of how durable they are.

Consumer-permissioned aggregation

The member authorizes a data aggregator — MX and Plaid both connect heavily into the credit-union segment, and MX in particular has deep reach among credit unions and community banks. This carries balances and posted transactions cleanly and survives front-end changes well, because the aggregator absorbs them. Field depth on Zelle status, the bill-pay calendar and the NYDIG ledger is usually shallower. We handle the aggregator onboarding and the FDX-aligned consent capture with you as part of the build.

Authorized member-session protocol integration

Southland authenticates members through Alkami's OpenID Connect flow. With the member's authorization, we work the consented session's token chain and the calls behind the dashboard to reach the fields aggregation thins out — pending Zelle, the scheduled bill-pay list, the FICO pull, the custodial bitcoin lots. More effort to stand up and more sensitive to platform releases, but it is the only way to get full fidelity on those rails.

Native member export

Digital Banking exposes statements and a transaction download to the member. As a fallback it is fine for periodic, member-initiated reconciliation; it is too coarse and too manual to be a primary sync. We would use it only to backfill or to validate the other two.

For Southland we would run aggregation as the spine and reserve the session route for the four fields it cannot reach with depth. That keeps the durable majority of the integration on the resilient path and isolates the brittle work to a small, well-understood surface.

What we account for on an Alkami-hosted credit union

These are the specifics this build has to get right, and how we handle each.

• The 30-day mobile-deposit gate. Per Southland's own help pages, mobile deposit is disabled for the first 30 days of membership. We model an empty deposit-history surface for a new member as the expected state, so the sync never reports it as a broken endpoint.
• The NYDIG sub-account is custodial and one-directional. Per NYDIG's published service description, members can buy, sell and hold but cannot move bitcoin to an external wallet. We represent it as a read-only holdings-and-lots view, so downstream code never attempts a transfer the platform will reject.
• Short-lived Alkami sessions and step-up auth. The OpenID Connect tokens expire quickly and can demand a multi-factor step-up. We design the consented pull around the refresh and step-up window so a long sync does not silently die mid-run.
• Platform releases move the front end. Alkami ships seasonal platform releases. Maintenance tracks that release calendar directly, so a screen Alkami changes is caught and patched before it can degrade a live integration.
• Three payment rails, one mental model. Internal transfers, ACH bill-pay and Zelle are distinct systems with distinct identifiers. We normalize them separately so a consolidated movement view does not conflate a Zelle send with a scheduled bill payment.

What ships at the end of a Southland build

You receive a working integration for the surfaces above, not a report about one. Concretely:

• An OpenAPI/Swagger specification covering the Southland surfaces in scope — accounts, transactions, bill-pay, Zelle, deposits, FICO, bitcoin holdings.
• A protocol and auth-flow report documenting the Alkami OpenID Connect token chain, refresh behaviour and the step-up path as they apply to a consented member session.
• Runnable source for the key endpoints in Python or Node.js — balance read, paged transaction pull, bill-pay schedule, Zelle history, NYDIG holdings.
• Automated tests, including the new-member empty-deposit case and token-refresh handling.
• Interface documentation and data-retention guidance written for member PII at an NCUA-insured institution.

A worked example: pulling posted transactions

Illustrative shape only — exact field names and the token endpoint are confirmed during the build against a consenting member account.

POST /oidc/token            # Alkami OpenID Connect, member-consented
  grant_type=refresh_token
  scope=accounts transactions
→ { "access_token": "<jwt>", "expires_in": 600 }   # short-lived; refresh before expiry

GET /accounts/{memberId}/transactions?from=2026-04-01&cursor=
  Authorization: Bearer <jwt>
→ {
     "account": { "type": "share", "mask": "1234" },
     "items": [
       { "postedDate": "2026-04-18", "amount": -42.10,
         "description": "BILL PAY - EDISON", "rail": "ach_billpay",
         "runningBalance": 1380.55, "status": "posted" },
       { "postedDate": "2026-04-17", "amount": -25.00,
         "description": "ZELLE TO J. DOE", "rail": "zelle",
         "status": "posted" }
     ],
     "nextCursor": "eyJ..."        # page until null
   }

# error handling: 401 -> refresh token and retry once;
#                  step_up_required -> surface MFA prompt, do not loop;
#                  empty items for a sub-30-day member -> expected, not failure

The rail tag is ours, not Southland's — it is how we keep Zelle, bill-pay and internal movement distinguishable downstream.

Where integrators take this

• Personal finance aggregation. Balances plus categorized posted transactions feed a budgeting product, with the bill-pay calendar driving due-date reminders.
• Lending and underwriting. A consent-scoped, time-boxed cash-flow and FICO pull supports a loan decision without a manual statement upload.
• Bookkeeping sync. Posted transactions flow into accounting software, deduplicated against the ledger so bill-pay entries are not double-counted.
• Crypto alongside fiat. The NYDIG bitcoin lots surface read-only beside fiat balances for portfolio and tax tooling.

The data-rights picture for a Southland member

Southland is a state-chartered, NCUA-insured California credit union, so the member — not the credit union — is the party who authorizes data sharing. No enforced federal mandate currently compels Southland to hand member data to third parties on request: the CFPB personal-financial-data-rights framework is not in force and is back in rulemaking, so in practice every pull rides the member's own consent. We work on that footing — explicit member authorization captured and logged, scope limited to the fields the use case needs, retention bounded, and an NDA where the engagement touches member PII.

Sources and what was checked

Reviewed in May 2026 against Southland's published digital-banking pages and help content, the credit union's own crypto-launch announcement, Alkami's platform documentation, and the CFPB's reconsideration docket; member-base and founding figures are from a third-party credit-union financials directory and are cited as such, not asserted independently.

• Southland CU — Digital Banking
• Business Wire — Southland CU launches mobile cryptocurrency service (NYDIG)
• Alkami — Online Banking Platform
• CFPB — Personal Financial Data Rights Reconsideration

Mapped by the OpenBanking Studio integration desk · May 2026.

What the app screens show

Store screenshots, useful for confirming surface labels before a build. Tap to enlarge.

Other California credit-union apps in the same shape

Same authenticated-member pattern, useful when a single integration needs to span more than one institution.

• SchoolsFirst FCU — California's largest credit union, serving educators; balances, transactions and transfers behind a member login.
• Golden 1 Credit Union — statewide California reach with over a million members and a full digital-banking surface.
• Logix Federal Credit Union — Southern California, with a well-rated app covering deposits, cards and transfers.
• Patelco Credit Union — Bay Area credit union with loans, cards and financial-wellness data per member.
• Star One Credit Union — Sunnyvale-based, deposit-heavy member accounts and transaction history.
• Premier America Credit Union — checking, loan and ATM-network data behind authenticated access.
• Financial Partners Credit Union — California member accounts with the same balance and transaction surfaces.
• Alliant Credit Union — a national, app-forward credit union frequently used by California members.

Questions integrators ask about Southland CU

Can you keep Zelle payments separate from internal transfers and ACH bill-pay in a Southland pull?

Yes. Zelle moves over a P2P network, internal transfers move between the member's own share and checking accounts, and bill-pay runs as scheduled ACH. We normalize the three as distinct rails so a downstream transfers view does not silently merge them.

Does the NYDIG bitcoin balance come through the same integration as the share accounts?

It surfaces alongside the fiat accounts but as a separate read-only custodial ledger. The NYDIG sub-account holds bitcoin lots and, per NYDIG's published service description, does not support external wallet transfers, so we model it as holdings you can report on, not a movable balance.

Mobile deposit only switches on 30 days after someone joins Southland — how do you handle a brand-new member?

Per Southland's own help pages, mobile deposit is gated for the first 30 days of membership. We treat an empty deposit-history surface for a new member as the expected state rather than an integration error, so the sync does not flag it as a failure.

Is there a US open-banking mandate that forces Southland to expose member data on request?

No mandate is currently enforced. Southland is a state-chartered, NCUA-insured credit union, and the CFPB personal-financial-data-rights framework is not in force and is back in rulemaking, so every pull rides the member's own consent. We build on that basis — explicit authorization, logged, scope-limited.

A balance-and-transaction pull with the Zelle and bill-pay rails normalized is a one-to-two-week build for Southland. You can take it as runnable source plus the OpenAPI spec, protocol report and tests for $300, settled only after delivery once you are satisfied; or skip the build and call our hosted endpoints, paying per call with nothing upfront. Give us the app name and what you want from its data and start the conversation here — access and the member-consent setup are arranged with you as part of the engagement.