Connecting SECU member accounts to your own systems

SECU members read their money through Member Access — the same login the mobile app drives. Balances, posted transactions, BillPay history, transfers, mobile check deposits and up to 18 months of statements all live behind one credentialed session, with a multi-factor step (passcode plus a security question, one-time passcode, or biometric) on the way in. That session is the surface we integrate against.

The practical problem for most teams is not whether the data exists; it is that SECU hands it back as a CSV download or an OFX file aimed at Quicken, neither of which streams. We close that gap by building a connector that holds a consented member session, watches for new activity on a schedule, and posts each new record to your system as a signed event. The recommended route, spelled out below, is that consented-session connector with the OFX feed as its primary source and the CSV export as a fallback — it is the most durable thing to build given how SECU exposes the data today.

What SECU holds, and where it lives in the app

Routes to the data, and the one we'd take

1 — Consented member-session connector (recommended)

The connector authenticates as the consenting member through SECU's own flow, completing the MFA step in-line, then pulls activity through the OFX channel and normalizes it. Reachable: balances, transactions, statements, and the BillPay/transfer records the session exposes. Effort is moderate; durability is good because we ride the member's legitimate access rather than anything brittle. We arrange the consenting test account or sandbox with you during onboarding.

2 — Protocol analysis of the app traffic

Where a record shows in the app but not in the OFX file, we map the app's own request and response shapes under your authorization and add those calls to the connector. This covers things like secure messages or deposit metadata that the export omits. Effort is higher; we re-validate it on a cadence because in-app endpoints move.

3 — Native export ingestion (fallback)

For any account the OFX feed will not serve, the connector drives the Member Access CSV download and parses it. Lowest effort, lowest freshness — useful as a backstop and for one-off backfills, not as the live path.

What ships

Delivery is code first. You get:

• A runnable connector in Python or Node.js: member-session auth (MFA handled), OFX pull, CSV fallback, normalization to a clean transaction/account schema.
• Webhook handlers that sign each event and post new activity to your endpoint, with a per-account cursor so a re-run resends nothing already delivered.
• An automated test harness covering the auth flow, OFX parsing, the cursor logic, and the CSV fallback against recorded fixtures.
• A sync design that states the poll cadence, the batch-vs-incremental split, and how a full backfill differs from the steady-state delta.
• An OpenAPI description of the normalized endpoints the connector exposes, plus a protocol and auth-flow write-up of SECU's session and OFX behavior.
• Interface documentation and data-retention notes covering consent records and what we keep versus discard.

The OpenAPI spec and the auth-flow report are part of the package; the headline is the connector that actually runs in your environment.

A look at the connector internals

Illustrative shape of the poll-and-push loop, confirmed against SECU's OFX behavior during the build:

# Poll an authorized SECU Member Access session, normalize OFX rows,
# push only new activity to the subscriber.

session = secu_login(member_id, secret, otp_callback=prompt_otp)   # MFA: passcode + OTP / biometric step
cursor  = store.get("org.ncsecu.mobile", account)                  # last seen OFX FITID

ofx = session.download_ofx(account_id=account, start=cursor.date)  # falls back to CSV export if OFX is refused

for txn in parse_ofx(ofx).statement_txns:
    if cursor.fitid and txn.fitid <= cursor.fitid:
        continue                                                  # already delivered
    event = {
        "account":  account,
        "fitid":    txn.fitid,        # OFX id, doubles as the dedupe key
        "posted":   txn.dtposted,
        "amount":   txn.trnamt,
        "memo":     txn.memo,
        "type":     txn.trntype,      # DEBIT / CREDIT / XFER
    }
    deliver_webhook(subscriber_url, sign(event))                  # HMAC-signed POST

store.set("org.ncsecu.mobile", account, ofx.last_fitid)
      

The auth call wraps SECU's multi-factor step; the FITID cursor is what lets the loop run on a schedule and still only emit transactions you have not seen.

Engineering details we plan around

A few specifics of SECU shape the build, and we handle each as part of the work:

• The OFX channel is restricted toward Quicken. SECU limits direct third-party use of OFX, per its Quicken download page. We design the connector to authenticate the way a sanctioned member client does and keep the CSV export wired as an automatic fallback, so a refused OFX session degrades to a working path rather than a failure.
• MFA sits on every session. Because login can demand a one-time passcode or a security answer on top of the passcode, we build the auth step to surface that challenge to a supplied callback and to refresh the session before it lapses, so a long-running sync is not interrupted mid-poll.
• Statement depth is bounded. SECU exposes roughly 18 months online, so any history beyond that window is a one-time archival task, not something the live feed can recover — we call that out in the sync design and plan the initial backfill around it.

Access to a consenting account or a sponsor sandbox is arranged with you during onboarding; it is something the project sets up, not a hurdle you clear before we start.

Consent and the US data-rights picture

The whole integration rests on the SECU member authorizing it, and we keep the consent record, log what is pulled, and minimize what we retain. NDAs are in place where the work touches anything sensitive. On the regulatory side: the CFPB's Section 1033 Personal Financial Data Rights rule was finalized, but it is currently enjoined and back in reconsideration at the Bureau (a federal court enjoined enforcement in late October, per the Cozen O'Connor alert cited below). We do not treat it as settled law or build the connector against obligations that may change. Member consent is the dependable basis we ship on today; the design leaves room to adopt a formal data-rights interface for SECU if one is finalized later.

Working with us, and what it costs

Most SECU connectors leave our desk inside one to two weeks of a settled scope. Buy the source outright — the runnable connector, tests and docs — from $300, paid only after delivery once it works to your satisfaction. Prefer not to run it yourself? Call our hosted endpoints instead and pay per call, with no upfront fee. Tell us the app and what you need from its data; we handle access, the consent flow and the compliance paperwork with you.

Talk to us about a SECU integration

How this brief was put together

Compiled in June 2026 from SECU's own service pages and the current regulatory record. Checked: SECU's online statements page (statement depth), its Quicken / OFX download page (the restricted export channel), the Google Play listing (package and feature set), and the Cozen O'Connor alert on the Section 1033 injunction and reconsideration.

OpenFinance Lab · interface assessment, June 2026.

Other credit-union apps in the same integration scope

• Navy Federal Credit Union — membership-gated banking app holding balances, transfers and card data behind an authenticated session.
• PenFed Credit Union — open-membership credit union with checking, savings, loans and mortgages in one portal.
• Alliant Credit Union — digital-first credit union with high-yield accounts and a transaction-rich app.
• Digital Federal Credit Union (DCU) — mobile banking with budgeting and credit-score features over server-side account state.
• BECU — Washington-based credit union exposing checking, savings and loan activity to members.
• Connexus Credit Union — nationwide digital credit union with the same balance/transaction surfaces.
• Coastal Credit Union — another North Carolina credit union with comparable Member-Access-style data.
• Truliant Federal Credit Union — NC-headquartered credit union holding accounts, payments and statements per member.

Inside the app

Questions integrators ask about SECU

Can you turn SECU's CSV and OFX exports into a live event stream?

Yes. SECU members can pull statement data as CSV or through the OFX/Quicken channel, but neither is a push feed. We wrap a consented member session in a connector that polls on a schedule, keeps a per-account cursor on the OFX FITID, and posts only the new rows to your endpoint as signed webhook events. Downstream you receive transactions as they post instead of re-parsing a whole statement.

Which SECU records can a consented connector reach?

Whatever the member sees in Member Access: account balances and transaction history, BillPay payees and payment history, transfers between SECU accounts and loan or card payments, mobile check deposit records, loan-advance activity, secure messages, and statements (SECU shows up to 18 months, per its online statements page). We map each to a normalized schema.

How does SECU's restricted OFX channel change the build?

SECU limits direct third-party use of its OFX channel and steers it toward Quicken, per its Quicken download page. We treat that as a design constraint, not a blocker: the connector authenticates as the consenting member through the same flow the app uses, with the MFA step handled in-line, and falls back to the Member Access CSV export for any account the OFX feed will not serve.

Where does US data-rights regulation leave a SECU integration right now?

The dependable basis today is the member's own authorization. The CFPB's Section 1033 Personal Financial Data Rights rule was finalized but is currently enjoined and back in reconsideration at the Bureau, so we do not build against it as settled law. We design for member-consented access now and structure the connector so it can adopt a formal data-rights interface if and when one is required of SECU.