Integrating First Service Credit Union: balances, cards, and statements over OFX

Per its Google Play listing the app ships as com.softek.ofxclmobile.firstservicecuapp, and that package name is the tell. The ofxclmobile prefix is Access Softek's mobile client, and Access Softek runs an Open Financial Exchange (OFX) server — the same documented protocol that pushes statements into tools like Quicken and QuickBooks. For an integrator that reframes the whole job: the cleanest way to a member's First Service balances and transactions is the OFX message set the platform was already built around, run under the member's own authorization. Houston is the market. The credit union is mid-sized, NCUA-insured, and state-chartered.

Bottom line: most of the money movement you'd want is reachable through OFX, and the surfaces OFX never modeled — card controls, alert preferences, Zelle counterparties, statement PDFs — come from the app's own backend. We build both and hand back one feed. The rest of this page is how that goes together.

What the member account holds

The features below are drawn from the app's own store description. Each maps to a data surface an integrator can read once the member consents.

Routes in

Three apply here. They are not mutually exclusive — a real build uses the first two together.

1 · OFX statement protocol

The spine. Because the platform speaks OFX, a member-authorized client can issue the standard statement request and read back posted transactions and balances for share accounts, and card transactions through the credit-card message set. Effort is low to moderate — it's an open, versioned standard, not a moving target — and durability is high. We set up endpoint discovery, the member-consented credentials, and an account enumeration pass so each account routes to the right request.

2 · Member-consented protocol analysis of the app backend

OFX stops at transactions and balances. Card controls, alert configuration, Zelle counterparty metadata, loan detail and eStatement PDFs live in the app's own digital-banking backend, so we map that traffic — the auth, token and session chain — under a consenting account. Effort is moderate; durability tracks the app's release cadence, which is why we re-validate the capture when the app updates rather than letting it drift.

3 · Native document export

eStatements and tax forms can be pulled as the member-facing PDFs the app already exposes. Coarse-grained, but durable, and a sensible fallback for anything document-shaped rather than transaction-shaped.

In practice the OFX pull carries the weight for money movement and balances, and the backend route fills the gaps OFX leaves. We'd build both and present them as a single account model, with native export reserved for documents.

What you get

Everything here is tied to First Service's actual surfaces, and it leads with code you can run:

• A runnable OFX client in Python and Node.js that authenticates as the member, issues the bank and credit-card statement requests, and parses each posted item into a typed record.
• A webhook handler that turns the app's account, card and loan alerts into normalized events pushed to an endpoint you control.
• Backfill plus incremental sync — a one-time history pull, then a cursor that advances on the latest posted date so subsequent runs read only what's new.
• An automated test suite built on recorded OFX fixtures and golden-file parser assertions, so a change in the response shape shows up the moment the parser disagrees with the fixture.
• The supporting paperwork once the code is settled: an OpenAPI description of the normalized endpoints, a short auth-flow report covering the OFX session and the backend token chain, interface documentation, and data-retention guidance.

On the wire

A statement pull against the OFX endpoint looks like the request below. The message tags are confirmed against the OFX 2.2 specification; the host and credentials are supplied by the member during onboarding.

<!-- Illustrative: member-authorized OFX statement pull, checking account -->
<OFX>
 <BANKMSGSRQV1>
  <STMTTRNRQ>
   <TRNUID>fscu-2026-06-08-001</TRNUID>
   <STMTRQ>
    <BANKACCTFROM>
     <BANKID>...</BANKID><ACCTID>...</ACCTID><ACCTTYPE>CHECKING</ACCTTYPE>
    </BANKACCTFROM>
    <INCTRAN><DTSTART>20260501</DTSTART><INCLUDE>Y</INCLUDE></INCTRAN>
   </STMTRQ>
  </STMTTRNRQ>
 </BANKMSGSRQV1>
</OFX>

# Each posted item returns as a <STMTTRN>; FITID is the server's stable id.
# We use FITID as the dedup key and remember the latest DTPOSTED as the next cursor.

Normalized to one record

OFX, the backend feed and the alert push all collapse into a single shape, so a consumer never has to know which protocol a field came from:

{
  "account_id": "chk-****1234",
  "type": "checking",
  "txn_id": "<FITID from OFX>",      // stable; never re-ingested
  "posted_at": "2026-05-31",
  "amount": -42.17,
  "name": "ZELLE TO J DOE",
  "status": "posted",                // pending entries held in a separate lane
  "source": "ofx:STMTTRN"
}

// Alert push (account / card / loan activity) -> your endpoint, event-time
{ "event": "card.transaction", "card": "deb-****9921", "amount": 88.40,
  "settles_against": "ofx:STMTTRN", "received_at": "2026-06-08T14:03Z" }

Authorization and the section 1033 question

The dependable basis for reading this data is the member's own consent. First Service is an NCUA-insured, state-chartered credit union, and a build runs on credentials the member agrees to share, with consent records, scoped access and data minimization in place from the start. We log what was read and keep the footprint to the fields the integration actually needs.

The CFPB's section 1033 personal-financial-data rule is where US open banking may eventually settle, but it is not the rule today: a federal court enjoined enforcement in late 2025 and the Bureau reopened it for reconsideration. A state-chartered credit union of this size was never among the first-wave data providers that rule front-loaded, so its obligations were not imminent even before the injunction. We track where the rule lands; we don't build on a regime that isn't in force. Member authorization is what the work stands on.

What we handle in the build

OFX gives you posted transactions and balances cleanly, but it was never meant to carry card controls, alert preferences, Zelle counterparty metadata or eStatement PDFs. We map those to the app's digital-banking backend and stitch both feeds into one account model, so whatever consumes the integration sees a single schema rather than two protocols.

The app surfaces pending direct deposits and an Early Payday preview before funds settle. We design the sync so pending entries sit in their own lane and only promote into the settled ledger once the server drops the pending flag — the balance math and any bonus-eligibility logic downstream stays correct rather than double-counting a preview.

One member can hold checking, savings, money-market, CD, credit-card and loan accounts at the same time, and each maps to a different OFX message set. We enumerate the member's accounts first, then route each to the correct request, which means adding a new account type later is a config change instead of a rewrite. Access to a sandbox or a consenting account is arranged with you as part of onboarding — it is something the project sets up, not a form you fill out before we start.

Pricing and how a build runs

The handover for First Service is concrete: an OFX client that authenticates as the member, parser code for the bank and card message sets, the alert webhook handler, and the tests around them. You can take that as source for a flat fee from $300, invoiced only after you have run it and signed off — or skip the build entirely and call our hosted endpoints instead, paying per call with nothing upfront. Either path, the first working drop lands within one to two weeks. Tell us the app and what you need out of it to get going: start a brief here. Access and compliance are arranged with you as part of the work.

Inside the app

Store screenshots, useful for reading the surfaces an integration touches. Select one to enlarge.

Other Houston credit-union apps

Same category, same kind of authenticated banking data — useful context if you're aggregating across more than one institution. Listed for ecosystem reach, not ranked.

• TDECU (Texas Dow Employees Credit Union) — one of the largest Houston-area credit unions; holds the same share, card and loan records behind a member login.
• Smart Financial Credit Union — Houston member-owned CU with checking, savings and lending data reachable under the member's consent.
• First Community Credit Union — broad Houston-area footprint; account, card and transfer surfaces comparable to First Service.
• PrimeWay Federal Credit Union — Houston federal CU with a full online and mobile banking suite over the same account types.
• Houston Federal Credit Union — accounts, loans and card activity that a unified integration would normalize the same way.
• People's Trust Credit Union — Houston-based CU; member balances, transactions and payments behind authenticated access.
• Community Resource Credit Union — Houston-area CU strong in auto lending, with loan and account data that fits the same schema.

How this was put together

Checked on 2026-06-08 against the app's store listings, the OFX standard, Access Softek's platform footprint, and the current status of US data-rights rulemaking. The OFX message tags here are read from the published specification, and the regulatory note from primary CFPB material — not assumed.

• Access Softek — OFX Server adoption across financial institutions (CUInsight)
• Open Financial Exchange — protocol overview and history
• CFPB — Personal Financial Data Rights (section 1033) reconsideration
• First Service Credit Union — digital banking features

OpenFinance Lab — protocol assessment, 2026-06-08.

Questions integrators ask

Does the OFX route cover credit cards and loans, or only checking and savings?

OFX carries posted transactions and balances for share accounts — checking, savings, money market and CDs — through the bank message set, and credit-card accounts through their own message set. Loan balances and payment history are thinner in OFX, so we read those from the app's own digital-banking backend and merge them into one schema.

How fresh is the feed — a nightly pull, or something closer to event-time?

Both. A scheduled OFX pull brings posted transactions and balances each day, keyed on the transaction IDs the server assigns so nothing is read twice. The app's account, card and loan alerts give an event-time signal on top of that, which we deliver as a webhook your stack receives as activity happens.

Direct deposits show as pending before they post, and Early Payday moves the date — how does that land in the data?

Pending entries and posted entries are tracked separately. We fold a pending direct deposit into a stable ledger only once it posts and the server stops marking it pending, so an Early Payday preview never double-counts against the settled balance.

What's the legal basis for reading a member's First Service Credit Union data?

The member's own authorization. First Service is an NCUA-insured, state-chartered credit union, and access runs on credentials the member consents to share, with consent records and data minimization built in. The CFPB's section 1033 personal-financial-data rule may formalize this later, but it is currently enjoined and back under agency reconsideration, so consent is the basis we build on today.

Last checked 2026-06-08