Reaching account data inside First Service Credit Union's Softek-built app

The package name gives the build its first foothold. com.softek.ofxclmobile.firstservicecuapp tells you First Service Credit Union does not run a one-off in-house app — it ships a Softek OFXCLMobile client, the same white-label digital-banking platform behind a long list of other credit unions on Google Play (Our Community Credit Union, Evolve FCU, United Credit Union and more share the com.softek.ofxclmobile.* prefix). That matters for integration. The login handshake, the session model and the request shapes follow a pattern we have seen before, so mapping First Service is faster than mapping a custom, in-house stack from zero. The backend host, the member base and the branding are still its own.

What a member sees after login is the real target: balances across checking, savings, money market and certificate accounts, dated transaction history, downloadable eStatements, transfers, loan-payment records, debit and credit card status, and Zelle send/receive events. The route we would take is member-consented protocol analysis of that authenticated traffic, normalized into a clean account-and-transaction model an outside system can read.

What the member portal holds

Authorized routes into the data

Three routes apply here. We size each one against what First Service actually exposes to a logged-in member.

Member-consented protocol analysis

We observe the authenticated traffic between the app and its Softek backend under a consenting member's authorization, document the auth flow and the account and transaction calls, and rebuild them as a clean connector. Reach is wide — anything the member can see in the app. Durability is good between front-end releases and best when we add a light re-validation step to maintenance. Access is arranged with you during onboarding, against a consenting member account.

Consumer-permissioned aggregation (FDX-style)

The US market is settling on the Financial Data Exchange model — OAuth 2.0 and OpenID Connect with standardized account, transaction and statement objects. Where First Service or its data-aggregator partners expose a consent-based feed, we connect through it and map the FDX objects to your schema. This is the most durable path when it is available for a given member, and we confirm availability as part of scoping rather than assuming it.

Native export as a fallback

The app already downloads eStatements as PDFs and the portal supports connecting external accounts for tracking. Where a live connector is not wanted, we build parsers that turn the member's own downloaded statements into structured records. Narrower and not real-time, but simple and low-maintenance.

For most teams the consented protocol-analysis route is the one worth building first: it reaches every surface a member sees today and does not wait on a third party's roadmap. We pair it with FDX-style aggregation where a member can use it, so the connector keeps working as US open banking matures.

A login-to-transactions sketch

Illustrative only — field names and the exact auth step are confirmed during the build against a consenting account. The shape below reflects the token-then-fetch pattern typical of the OFXCLMobile platform.

# Illustrative connector for a Softek OFXCLMobile-style backend.
# Auth specifics confirmed during the build under member consent.

import requests

session = requests.Session()

def login(username, password, otp_callback):
    # Step 1: credential post returns a challenge for the OTP step
    r = session.post(f"{BASE}/auth/login",
                     json={"user": username, "secret": password})
    r.raise_for_status()
    if r.json().get("mfa_required"):
        code = otp_callback()                 # one-time passcode the app sends
        r = session.post(f"{BASE}/auth/mfa", json={"code": code})
        r.raise_for_status()
    return r.json()["access_token"]           # bearer token for later calls

def accounts(token):
    r = session.get(f"{BASE}/accounts",
                    headers={"Authorization": f"Bearer {token}"})
    r.raise_for_status()
    return r.json()["accounts"]               # id, type, balance, available

def transactions(token, account_id, since):
    r = session.get(f"{BASE}/accounts/{account_id}/transactions",
                    headers={"Authorization": f"Bearer {token}"},
                    params={"from": since})
    if r.status_code == 401:                  # token expired -> re-auth, retry
        raise SessionExpired
    r.raise_for_status()
    return [normalize(t) for t in r.json()["transactions"]]

def normalize(t):
    # Map to an FDX-like row: postedDate, amount, description, status
    return {"date": t["postedDate"], "amount": t["amount"],
            "memo": t["description"], "status": t.get("status", "posted")}
      

What lands at the end of the build

Each deliverable is tied to a First Service surface, not a generic checklist:

• An OpenAPI/Swagger spec describing the account, transaction and statement endpoints as the connector calls them.
• A protocol and auth-flow report covering the credential post, the one-time-passcode step, and how the bearer token or session is refreshed.
• Runnable source in Python or Node.js for login, account listing, transaction pulls and statement retrieval.
• Automated tests that exercise the auth handshake, pagination of transaction history, and token-expiry retry.
• Interface documentation plus data-retention and consent-logging guidance suited to a credit-union member's data.

Consent and the US data-rights picture

First Service is a member-owned Houston credit union, so the firm basis for reaching a member's accounts is that member's own authorization — the same standing they have to log in and read their data. We work from that authorization, keep consent records, log access, minimize what is pulled to what the project needs, and sign an NDA where the engagement calls for one.

The federal rule people expect to govern this — the CFPB's Personal Financial Data Rights rule under Section 1033 — is not settled. A court enjoined enforcement in late 2025 and the Bureau put the rule back into reconsideration, so it is the forward-looking piece, not current law. We design around member consent today and keep the connector ready to ride an FDX-style consented feed if and when the reconsidered rule lands.

Engineering details we plan around

Two specifics shape how we build for First Service.

First, the shared Softek platform cuts both ways. Because OFXCLMobile sits behind many credit unions, we reuse the auth and transport patterns we have mapped on sibling clients, which shortens scoping. We still pin every endpoint, host and field to First Service's own backend and re-check them, because a white-label vendor can change a shared component and shift several institutions at once — so we wire a re-check pass into maintenance that flags drift after a platform update.

Second, the login uses a one-time-passcode step. We design the connector to carry the member through that challenge under their authorization and to refresh the session the way the app does, rather than re-prompting on every call. Access for the build — a consenting member account or a sandbox — is arranged with you during onboarding, not something you need lined up before we begin.

Where teams put this data to work

• A personal-finance app that pulls a member's First Service balances and transactions into a single net-worth view alongside their other institutions.
• An accounting tool that ingests eStatements and posted transactions to keep a small business's books current without manual entry.
• A lender pulling consented transaction history for income and cash-flow verification during underwriting.
• A treasury dashboard syncing balances across checking, savings and certificate accounts on a schedule.

Screens we mapped

Store screenshots we reviewed while sketching the data surfaces. Tap to enlarge.

Other credit-union apps in the same integration picture

Same category, same kind of authenticated member data — useful when a project needs more than one institution under one schema. Listed for context, not ranked.

• First Community Credit Union — large Houston credit union holding member checking, savings and loan records.
• Texas Bay Credit Union — Houston member accounts, transfers and statements behind a login.
• Houston Federal Credit Union — checking, savings and lending data for its members.
• TDECU (Texas Dow Employees Credit Union) — one of the larger Texas credit unions, with full account and card data.
• Greater Texas Credit Union — member balances, transactions and loan servicing.
• Evolve Federal Credit Union — another Softek OFXCLMobile client, with similar account and P2P surfaces.
• United Credit Union — Softek-platform sibling holding member accounts and transaction history.
• Our Community Credit Union — Softek-platform sibling with balances, transfers and remote deposit.

How this was put together

Checked in June 2026: the app's Google Play and Apple App Store listings and the First Service Credit Union site for the feature set and data surfaces; the shared com.softek.ofxclmobile.* package family on Google Play to confirm the Softek OFXCLMobile platform; America's Credit Unions and the CFPB for the current §1033 status; and the Financial Data Exchange material for the FDX/OAuth direction.

• Google Play listing — First Service Credit Union
• First Service Credit Union — digital banking features
• CFPB — Personal Financial Data Rights reconsideration
• America's Credit Unions — latest on the CFPB open banking rule

Mapped by the OpenBanking Studio integration desk, June 2026.

Questions integrators ask about First Service

Does the First Service app run on a shared platform, and does that change the build?

Yes. The Android package com.softek.ofxclmobile.firstservicecuapp shows the client is built on Softek's OFXCLMobile white-label platform, which a number of other credit unions also ship. The auth handshake and transport shape are consistent across those sibling apps, so the mapping work moves quickly, but the backend host, branding and member scope are specific to First Service and we treat each one on its own.

Which US rule decides whether a member's data can be pulled here?

The dependable basis is the member's own authorization to access their accounts. The CFPB's Personal Financial Data Rights rule under Section 1033 is not in force as of mid-2026 — a federal court enjoined enforcement and the Bureau reopened it for reconsideration in 2025 — so we treat it as where US open banking may go, not as today's governing requirement.

Do Zelle and mobile check deposits show up in the data we can capture?

Both surface as posted or pending transaction records. Zelle send and receive events read as dated transactions tied to an account, and remote check deposits appear as credits, sometimes with a status that moves from pending to posted. We model them as normal transaction rows rather than separate feeds.

How do you handle the app's two-step login when building the connector?

We replicate the documented login and one-time-passcode step under a consenting member's authorization during the build, then design the connector to refresh its session the same way the app does so the integration keeps working without re-prompting on every call.

Engagement is simple, and the price is the place to start: source-code delivery begins at $300, where you get the runnable connector and its documentation and pay only after delivery once you are satisfied; or run against our pay-per-call hosted API with no upfront fee and pay only for the calls you make. A working build for First Service typically takes one to two weeks. Tell us the app name and what you need from its data — access and any compliance paperwork are arranged with you — and start the conversation here.