Reaching the member data behind Desco FCU Mobile

Desco Federal Credit Union serves members across counties in southern Ohio, eastern Kentucky and western West Virginia, per the credit union's own site, and its mobile app puts that membership's deposit and loan accounts behind a single authenticated session. That session is where the value sits for an integrator: checking and savings balances, mortgage and auto-loan positions, posted transactions, mobile check deposits, transfers and bill payments — all keyed to one member login. The app's enrollment flow is served from a COCC “My Virtual Branch” endpoint, which points to COCC as the digital-banking core the app speaks to. Reaching that data is an exercise in authorized interface integration, not guesswork.

The route we would actually run for Desco is authorized protocol analysis of the app's own session against the COCC backend, with a consenting member login as the access path and native eStatement or OFX download filling in document history. That gives clean, repeatable reads of the same data a member sees, without standing up anything the credit union has not approved. The rest of this page sets out what is reachable, how the work is done, and what lands in your repository.

Member data the app actually surfaces

These rows track the app's own feature names. Card on/off and fraud alerts are deliberately listed as the companion app, because that is where they live.

Authorized paths into that data

Three routes apply to Desco. Access, onboarding and any sandbox are arranged with you and the credit union as part of the work — none of this is a checklist you clear before we start.

Protocol analysis of the app session

We capture and document the authenticated traffic between the app and its COCC-hosted backend, then rebuild the calls that return balances, transactions and deposit status. Reach is broad and matches what the member sees. Effort is moderate; durability is good as long as a maintenance check tracks front-end changes. This is the path we recommend for Desco, because it gives the cleanest reads of the live data.

Member-consented login access

With a consenting member, an aggregation-style login reaches the same portal surfaces. It is quick to stand up and useful for read-only balance and transaction pulls. The trade-off is the consent-refresh window, which we design the sync around so a session does not lapse silently.

Native export as a backstop

The online banking portal produces eStatements and supports transaction download (OFX/CSV-style), which covers historical documents that a live session does not page back far enough to reach. We wire this in for archival and reconciliation rather than real-time reads.

What a balance pull looks like

Illustrative only — exact paths and field names are confirmed during the build, not asserted here. The shape below reflects a session-based read of deposit and loan accounts in one list, with the current-versus-available distinction the app itself draws.

import httpx

class DescoSession:
    # COCC "My Virtual Branch" tenant; host fixed during the build
    BASE = "https://<digital-banking-host>/api"

    def __init__(self, member_token):
        # token comes from the consented login / captured auth flow
        self.client = httpx.Client(
            headers={"Authorization": f"Bearer {member_token}"},
        )

    def accounts(self):
        r = self.client.get(f"{self.BASE}/accounts")
        r.raise_for_status()
        # share/deposit + loan products return together
        return [
            {
                "id": a["accountId"],
                "kind": a["type"],          # CHECKING | SAVINGS | MORTGAGE | AUTO_LOAN
                "current": a["currentBalance"],
                "available": a.get("availableBalance"),  # None for loans
            }
            for a in r.json()["accounts"]
        ]

    def transactions(self, account_id, since):
        r = self.client.get(
            f"{self.BASE}/accounts/{account_id}/transactions",
            params={"from": since},
        )
        if r.status_code == 401:        # session lapsed -> run consent refresh
            raise SessionExpired
        return r.json()["items"]

What lands in your repo

Everything is tied to the surfaces above, not a generic template. You receive:

• An OpenAPI/Swagger spec covering the accounts, transactions, deposit-status and transfer calls.
• A protocol and auth-flow report documenting the login, token and session-cookie chain against the COCC backend.
• Runnable source for the key endpoints in Python or Node.js, with the current/available split and loan handling already modelled.
• Automated tests, including a fixture that exercises the 401 re-auth path.
• Interface documentation plus compliance and data-retention guidance for member-consented reads.

One account shape across Desco's products

Deposit and loan accounts come back in the same list, so we normalize them into a single object an external system can consume. Pending mobile deposits ride along as holds.

{
  "account": {
    "source": "desco-fcu-mobile",
    "type": "auto_loan",
    "balances": { "current": -18432.55, "available": null, "currency": "USD" },
    "holds": [
      { "reason": "mobile_deposit", "amount": 250.00, "status": "processing" }
    ]
  }
}

Consent, and where the US data-rights picture stands

For a federally chartered credit union like Desco, the dependable footing is the member's own authorization to reach their accounts. We operate under Gramm-Leach-Bliley privacy obligations and the NCUA's expectations for member data, with access logged, consent recorded, data kept to what the integration needs, and an NDA where the engagement calls for one. The CFPB's Personal Financial Data Rights rule under Section 1033 is the part still in flux: it was enjoined in late 2025 and sent back to the agency for reconsideration, so it is not current law and we do not treat it as the governing framework. If and when federal data-access rules settle for an institution of Desco's size, the consent-based design here moves toward them without a rebuild.

Build notes specific to this app

Two details shape the work, and we handle both inside the project rather than handing them back as conditions.

• Card controls are split off into the separate Desco My Card app, so we map which surfaces come from the main banking session and which from the card endpoint, and we do not assume both answer the same call.
• The app runs on a COCC digital-banking tenant whose front end gets updated; when that happens field names or the login challenge can shift, so we keep a maintenance check that replays the captured flow against the live site and flags drift before a sync breaks.
• Available balance is not the same as current balance here, and a freshly captured check shows as processing, so our hold logic keeps the two apart instead of double-counting funds.

Screens we mapped

Store screenshots we reviewed while scoping the surfaces above. Select one to enlarge.

Other credit-union apps in the same integration space

Members often hold accounts at more than one institution, so a unified view usually means mapping several of these alongside Desco. Listed for context, not ranked.

• KEMBA Financial Credit Union — Central Ohio member banking with balances, transfers and bill pay behind one login.
• Kemba Mobile (Cincinnati) — checking, transaction search, mobile deposit and card on/off for a separate Ohio/Kentucky credit union.
• BMI Federal Credit Union — Dublin, Ohio member app covering balances, transfers and message access.
• Wright-Patt Credit Union — large Dayton-area app with mobile deposit, biometric login and credit-score monitoring.
• Atomic Credit Union — southern Ohio member app with account views and mobile deposit.
• Members 1st FCU — member banking with account opening and loan applications alongside balances.
• Alliant Credit Union — nationwide member app spanning balances, transfers, bill pay and card actions.
• FedChoice Federal Credit Union — member app with the same deposit-and-transfer surfaces an aggregator would read.
• AlaTrust Credit Union — community credit-union app holding the comparable authenticated balance and transaction data.

Questions integrators ask about Desco FCU Mobile

Does the work cover both the main Desco app and the separate Desco My Card controls?

It can. The main banking session carries balances, transactions, transfers and deposits, while card on/off and fraud-alert controls live in the companion Desco My Card app, which talks to a different endpoint. We scope which surfaces you need and map each from where it actually originates, rather than assuming card controls sit inside the banking session.

Which US rules apply to member data pulled through Desco FCU Mobile?

The dependable basis is the member's own authorization to access their accounts, handled under Gramm-Leach-Bliley privacy obligations and NCUA expectations for a federally chartered credit union. The CFPB Personal Financial Data Rights rule under Section 1033 is the forward-looking piece: it was enjoined in late 2025 and is back in agency reconsideration, so it is not current law and we do not build on it as if it were.

Can you separate current balance from available balance and pending mobile-deposit holds?

Yes. The app shows current and available figures separately and surfaces a processing state on freshly captured check deposits, so our model carries both balance fields plus a holds list, and available-balance logic accounts for a deposit that has posted to the ledger but not yet cleared its hold.

Will a COCC digital-banking update break the integration?

It can shift field names or the login challenge, which is why we keep a maintenance check that re-runs the captured flow against the live front end and flags drift before a sync fails. When Desco's COCC tenant changes, we adjust the affected calls; routine upkeep of this kind is part of how we run the integration.

What we checked, and when

We read the app's own Google Play listing for its feature set and package id, the credit union's site for its membership footprint, COCC's digital-banking material for the platform the enrollment endpoint points to, and current CFPB and court reporting for the Section 1033 status. Primary sources:

• Desco FCU Mobile on Google Play
• COCC — Digital Banking
• CFPB — Personal Financial Data Rights (Section 1033)
• ABA Banking Journal — court halts Section 1033 enforcement

Mapped by the OpenBanking Studio integration desk, June 2026.

Runnable source for the Desco endpoints lands in your repository with the OpenAPI spec, tests and interface docs above; you pay from $300 after delivery, once it is running to your satisfaction. Prefer not to host anything? The same flows are available as a metered hosted endpoint, billed per call with nothing upfront. Either way the cycle is one to two weeks — tell us the app and what you need from its data at /contact.html and we will scope it.