A member-consented route into Century Federal Online Banking

Behind a CFCU Online login sits a member's whole standing at Century Federal Credit Union — share savings and checking, plus home, auto and other loan balances — alongside the enriched transaction stream and savings-goal progress the app puts on screen. Reaching that programmatically, with the member's say-so, is what this brief scopes. Century Federal is an NCUA-chartered federal credit union out of Northeast Ohio (charter #5852 per its NCUA record, with roughly 25,600 members and about $348M in assets per its latest call report).

Account picture and the route we'd take

The bottom line for a single credit union this size: there is no in-force federal interface to point an integration at, and the app guards itself with a one-time passcode step on unfamiliar devices. So the read we'd actually stand up is a consented session against the member's own account, returning the same JSON the app renders. Statement export covers older history coarsely; an aggregator connection only enters the picture if the member already keeps one.

What CFCU Online holds server-side

Each row below is a surface the app exposes to its members. Granularity is what a consented read can resolve, not a guess at the backend.

Getting to that data

Member-consented credentialed read

With the member's consent we replay the authenticated session — login, the OTP step-up, and the token or cookie chain that follows — against their own credentials, then read the JSON the app already receives. Reachable: everything the member sees, enrichment included. Effort is moderate, mostly in handling the device-recognition and step-up logic cleanly. Durability tracks the portal front end, so we wire a re-check into maintenance. Setup we run with you: capturing consent, handling credentials under NDA, and pointing the build at a consenting account.

Aggregator-mediated connection

Where Century Federal is already reachable through a consumer-permissioned aggregator network, reads can run over that link instead. Reachable: balances, transactions, identity, account and routing numbers. Effort drops when a connector exists; durability is higher because the aggregator carries the maintenance. Setup: the aggregator account, item linking, token storage.

Native statement export

Online banking lets a member pull statements and transaction files. Reachable: statement-level history in CSV or OFX/QFX form. Effort is low and durability high, but it is coarse — no real-time posting, no enrichment layer. We schedule retrieval and parse the files into the same shape as the live read.

For Century Federal specifically, the read worth building first is the consented credentialed one, because it returns the enriched transactions and goal progress the export files leave out. The export path stays in as a cheap way to backfill older statements, and we only reach for an aggregator link when the member already has that connection in place.

What you receive at handoff

Everything maps to the surfaces above, not a generic banking template:

• An OpenAPI 3.1 specification for the normalized endpoints — accounts, transactions, transfers, goals — with the field shapes a CFCU read returns.
• A protocol and auth-flow report: the login to OTP step-up to session-token chain, how device trust is established, and how the session refreshes.
• Runnable source in Python and Node.js for the core calls — session establishment, account list, paginated transaction pull, goal read.
• An automated test harness that replays recorded fixtures, so a front-end change shows up as a failing assertion instead of a silent data gap.
• Interface documentation mapping every field back to its CFCU Online surface.
• Compliance and retention notes: consent records, data minimization, GLBA-aligned handling.

A session and a pull, sketched

Illustrative shapes, not copied constants — exact field names get confirmed against a live read during the build. The 401 path re-establishes the session; pagination follows a cursor.

# Member-consented read against the CFCU Online session.

POST /auth/login            { username, password, deviceId }
   -> 200 { sessionToken, mfaRequired: true, mfaChannels: ["sms","email"] }

# OTP step-up fires once for an unrecognized device (per the app's own notice).
POST /auth/otp/verify       { sessionToken, code }
   -> 200 { sessionToken, deviceTrusted: true }

GET  /accounts              Authorization: Bearer <sessionToken>
   -> 200 [ { accountId, type: "loan|share|checking",
              balanceCurrent, balanceAvailable } ]

GET  /accounts/{id}/transactions?cursor=...&limit=100
   -> 200 { items: [ { postedAt, amountCents, rawDescription,
                       merchant, category } ],   # enrichment kept beside raw
            nextCursor }
   -> 401  => re-run /auth/login, reuse trusted deviceId, resume at cursor

Where US data-sharing rules sit for a credit union this size

Century Federal is a federally chartered, NCUA-insured credit union, so member data handling runs under the Gramm-Leach-Bliley framework. There is no in-force federal open-banking mandate to anchor an integration to right now: the CFPB's Personal Financial Data Rights rule that would have set one was enjoined, and the agency reopened it for reconsideration in 2025. We treat that rule as where things may go, not as today's basis. What we build on instead is concrete and durable — the member authorizing access to their own data, with consent captured up front, scoped to the domains they pick, and revocable. The OTP step-up actually helps here, since the member takes part in each authorization. We log access, keep consent records, and minimize what is pulled to what the use case needs.

What we plan around on this build

Two things about CFCU Online shape the engineering, and we handle both from our side.

The one-time passcode step. Century Federal sends an OTP by text or email for unrecognized devices and high-risk actions (per the app's own description). We design the session flow around that step-up — registering the consenting member's device once during onboarding so a scheduled read isn't re-challenged every run — rather than treating it as something to fight.

Enrichment sitting on top of the ledger. The app presents cleaned merchant and category data over the posted record. We capture the raw posting and the enrichment layer separately, so downstream categorization isn't locked to CFCU's taxonomy and your reconciliation still ties to the bank's own line.

The mortgage single sign-on. Mortgage payments hop through an SSO to a separate servicer. We map that token handoff during the build so loan and mortgage reads resolve against the right backend instead of failing quietly. And because the listing notes a v6.0+ client floor, we pin the client signature to the current app version and re-validate when Century Federal ships a new build.

Where teams put CFCU data

• A lending platform pulls a consenting member's CFCU balances and enriched cash flow to underwrite a loan without a manual statement upload.
• A personal-finance app mirrors Century Federal accounts beside other institutions for one net-worth view.
• A small-business accounting tool reconciles a member's bill-pay outflows against its own ledger.
• A financial-wellness product reads the FinHealth Score and savings-goal progress to coach the member against real numbers.

Keeping the read current

There is no push feed, so freshness comes from polling on a schedule the use case needs — a few times a day for a PFM mirror, on demand for an underwriting pull. We size the cadence to typical posting times so you are not re-reading an unchanged ledger. When the portal front end changes, the test harness flags it and we run a re-validation pass before data drifts.

Screens we worked from

Public store screenshots used while mapping the app's surfaces. Select to enlarge.

Other credit-union apps in the same picture

Teams integrating Century Federal usually want the same read across several institutions a member banks with. These are real same-category apps, framed for that unified view, not ranked:

• Navy Federal Credit Union — the largest US credit union app, holding balances, transactions and loans behind member login.
• PenFed Credit Union — Pentagon Federal's app, with checking, savings, cards and loan servicing data.
• Alliant Credit Union — a branchless credit union with built-in goal and budgeting data alongside balances.
• BECU — Boeing Employees' Credit Union, holding member deposits, transactions and loan accounts.
• Digital Federal Credit Union (DCU) — accounts, transfers and loan records across a broad member base.
• NASA Federal Credit Union — member deposit and lending data in the same digital-banking mould.
• Hanscom Federal Credit Union — New England credit union with comparable account and transaction surfaces.
• Allegacy Federal Credit Union — member balances, payments and loan detail behind authenticated access.

How this brief was built

Checked on 2026-06-15 against the app's own store listings, Century Federal's NCUA record, and current US data-rights filings. Primary sources opened:

• CFCU Online on Google Play — feature list and the v6.0+ client note.
• Century Federal Online Banking on the App Store — iOS listing and feature parity.
• Century Federal Credit Union NCUA profile (charter #5852) — membership and call-report figures.
• CFPB Personal Financial Data Rights reconsideration — current status of the §1033 rulemaking.

OpenBanking Studio integration desk · mapping compiled June 2026.

Questions integrators ask about CFCU Online

Does Century Federal's one-time passcode step stop a scheduled read?

No. The OTP that CFCU Online sends by text or email fires when it sees an unrecognized device. We register the consenting member's device once during onboarding, so the step-up clears a single time and the scheduled read then runs against the established session.

Can you keep Century Federal's enriched transaction data separate from the raw ledger?

Yes. The app shows cleaned merchant and category data on top of the posted record. We capture both layers, so your side keeps the raw transaction and can either use CFCU's enrichment or apply your own categorization.

Is there a federal open-banking rule that covers a credit union the size of Century Federal?

Not an in-force one as of 2026. The CFPB rule that would have defined a data-sharing interface was enjoined and is back in agency reconsideration, so the build relies on the member's own authorization rather than a federal mandate.

What does the Snapshot pre-login view mean for reading balances?

Snapshot surfaces account balances on the device before a full login. We treat it as a lighter-auth balance surface and pull richer transaction history from the authenticated session, scoping each read to what the member has consented to share.

Starting a build with CFCU Online

Send us "Century Federal Online Banking" and the fields you need — the account list, enriched transactions, goal progress — and we scope it from there. Source code for the CFCU endpoints runs from $300, billed after delivery once you've checked it against a live read; the hosted-API option charges per call with nothing up front. Either way the cycle is one to two weeks. Begin at /contact.html.