Getting at SkyPoint FCU member data on its shared banking core

SkyPoint Federal Credit Union runs its member app as one tenant on a shared white-label banking platform, keyed by the institution id fiid3935 in the Android package com.ifs.androidmobilebanking.fiid3935 (per its Play Store listing). That single fact decides almost everything about how the integration is built, so it is the place to start rather than the feature list. The credit union itself is small and regional — based in Germantown, Maryland, serving the greater Washington, DC area, renamed from Montgomery County Employees Federal Credit Union in 2019 after a community-charter expansion (per American Banker's reporting). The data behind the login is ordinary retail-banking data, and it is real. The platform it sits on is the interesting part.

Bottom line: there is no regulator-operated data feed to point at for a credit union SkyPoint's size today, and there does not need to be. The reachable surface is the authenticated member session — the same one the app and the /dbank/live/app web login use. We map that session, scope every call to tenant 3935, and hand back runnable source plus a spec. The route below is the one we would actually take.

What member data the app actually holds

These are the surfaces SkyPoint names on its own digital-banking page and in the store listing, not a generic banking checklist. Granularity is per the member's accounts at session time.

Reaching the fiid3935 tenant

Four routes are worth weighing here. They are not equal.

1 · Authorized interface integration of the member session

Protocol analysis of the SkyPoint mobile and /dbank web traffic, scoped to tenant 3935, run under the credit union's or the member's consent. Reaches everything in the table above, because it reads exactly what the member sees. Medium effort, good durability with maintenance. Access — a consenting member session or a sponsor arrangement with the credit union — is set up with you during onboarding; it is part of the project, not something you hand us first.

2 · User-consented access through a US aggregator

An established aggregator that already maps shared com.ifs-style cores can broker balances and transactions under the member's permission. Lighter to stand up, but coarser: bill-pay detail, offers and statement documents are usually thinner or absent, and you inherit the aggregator's coverage decisions for a credit union this small.

3 · FDX-aligned consented access

If and when a Section 1033-style framework settles for institutions SkyPoint's size, an FDX endpoint would give standardized account and transaction objects with high durability. It is not callable for a credit union this size right now, so it is a target to shape output toward, not a route to build on today.

4 · Native export

E-Statements give a member 24 months of statement documents to pull. Useful as a supplement for archival, weak as a spine — there is no bulk structured export behind it.

Route 1 is the backbone we would actually build SkyPoint on. Route 2 is the lighter pick when a caller only needs balances and a transaction feed and can live with aggregator-grade coverage. We would wire the output of either to the same FDX-shaped schema so route 3 is a swap, not a rebuild, later.

A look at the login and statement calls

Illustrative shape only — the exact host and paths are confirmed against a consenting SkyPoint session during the build and are not asserted here as fixed constants.

# Tenant-scoped session on the shared com.ifs core
POST {platform-host}/dbank/live/app/login/consumer
  fiId   = 3935            # SkyPoint's tenant; NOT a sibling CU
  user   = <member>        # credentials handled under member consent
  device = <bound-id>
-> 200 { sessionToken, mfaState }

# History comes from the live session, not the 5-row watch summary
GET {platform-host}/dbank/live/app/accounts?fiId=3935
  Authorization: Bearer <sessionToken>
-> [ { acctId, type, available, current } ]

GET {platform-host}/dbank/live/app/transactions
  ?acctId=<id>&from=<YYYY-MM>&to=<YYYY-MM>
-> [ { postedDate, amount, description, category } ]
# Statement depth tracks the documented 24-month E-Statement
# window; we surface that horizon to downstream consumers.

# Error handling we build in:
#   401 / mfaState=challenge  -> step-up, do not retry blind
#   tenant mismatch on fiId    -> hard fail, never fall through
      

What lands at the end of the build

Concrete artifacts, tied to SkyPoint's actual surfaces:

• An OpenAPI/Swagger specification covering accounts, transactions, transfers, bill pay, deposits and statement retrieval for tenant 3935.
• A protocol and auth-flow report: the login, MFA step-up and session-token chain on the com.ifs core, written down so it can be re-derived.
• Runnable source for the key endpoints in Python and Node.js — login, account list, transaction range, statement pull — with the tenant-scoping baked in.
• Automated tests, including a contract test that fails loudly if the /dbank front end changes shape.
• Interface documentation and data-retention guidance scoped to a consented credit-union context.

Output is normalized to FDX-style account and transaction objects so it drops into existing aggregation tooling and survives a later route swap.

Where SkyPoint sits on US data-rights today

SkyPoint is an NCUA-chartered federal credit union, so its member-data access would, in a settled world, run through the CFPB's Section 1033 personal-financial-data-rights framework. That rule is not in force the way it was written: it is stayed while the CFPB reconsiders it under new rulemaking (per the CFPB's own Section 1033 regulation page and credit-union trade reporting). For a credit union SkyPoint's size there is no regulator-operated data endpoint to call right now, and we do not state the rule's compliance dates as settled obligations because they are exactly what is being reconsidered. None of that blocks the work. Authorized interface integration under the credit union's or the member's consent does not depend on the rule being live; we keep consent records, log access, minimize retained fields to what the integration needs, and operate under an NDA where the engagement calls for one. The FDX-shaped output means that if a framework does settle for institutions this size, you are already aligned to it.

What we plan around on a shared-core build

These are the things this specific app makes us account for — handled on our side, not a list you have to clear.

• Tenant isolation. The com.ifs core is multi-institution. We scope every call to fiId=3935 and treat any tenant mismatch as a hard failure, so the integration can never read another credit union's data by accident on a shared host.
• The watch surface is a decoy. Wear OS shows only a balance and the last five transactions. We pull full history from the primary session and never let the integration silently truncate at five rows because that is all the smartwatch path returns.
• Statement horizon. E-Statements expose 24 months as the credit union describes them. We walk the statement index month by month inside that window and flag the boundary downstream so a consuming system knows the history depth instead of assuming it is unlimited.
• Front-end drift. When SkyPoint's web tenant at /dbank/live/app shifts, our contract tests fail before stale data reaches you, and refreshing the parser is part of how we keep the integration alive after delivery.

Keeping the SkyPoint integration current

White-label cores get updated on the vendor's schedule, not the credit union's, so an integration built once and left alone degrades quietly. We treat the contract test as the canary: it runs against a consented session, checks the account and transaction shapes against the spec, and signals before a field rename or an MFA change starts dropping data. Statement retrieval is checked at the 24-month boundary specifically, since that edge is where silent truncation tends to appear. Freshness of the data itself is session-time — balances and transactions are as current as the member's live session, not a delayed batch.

App screens we mapped

Store screenshots used to confirm the surfaces above. Tap to enlarge.

What was checked, and when

We read SkyPoint's own digital-banking page for the exact feature names and the 24-month statement window, the Play and App Store listings for the package and tenant id, American Banker's coverage for the charter and name history, and the CFPB's Section 1033 regulation page plus credit-union trade reporting for the current rule status. Sources, opened May 2026:

• SkyPoint FCU — Digital Banking features
• SkyPoint FCU on Google Play (package / fiid3935)
• CFPB — Personal Financial Data Rights (Section 1033)
• American Banker — charter expansion and name change

Compiled by the OpenBanking Studio integration desk — reviewed 2026-05-18.

Other credit-union apps in the same space

Neutral context, not a ranking — a unified integration usually has to span several of these:

• Andrews Federal Credit Union — DC-area member app holding accounts, transfers and remote deposit.
• NASA Federal Credit Union — Maryland-based credit union app with accounts, statements and card controls.
• Pentagon Federal Credit Union (PenFed) — large credit union with broad account and loan data.
• Alliant Credit Union — digital-first credit union app: balances, transactions and mobile deposit.
• Delta Community Credit Union — full account portal for a large Georgia credit union.
• Lake Michigan Credit Union — regional credit union app with accounts and bill pay.
• Eastman Credit Union — credit union app with smartwatch and quick-balance surfaces.
• Associated Credit Union Mobile — runs on the same com.ifs white-label family under fiid3919, a near-mirror integration target.

Questions integrators ask about SkyPoint

The app runs on the shared com.ifs platform under fiid3935 — does that change how the integration is built?

It is the thing that shapes it. SkyPoint is one tenant on a multi-institution white-label core, so every request has to be scoped by the institution id 3935 to hit SkyPoint's data and not a sibling credit union on the same host. We confirm the live host and path during onboarding against a consenting member session, then pin the integration to that tenant.

Can you reach transaction history beyond the 24-month window the E-Statements show?

History depth tracks the 24-month E-Statement window the credit union documents online. We read transactions from the live session rather than the statement archive, walk the available periods, and flag the history horizon downstream so a consuming system never assumes unlimited depth.

With the CFPB Section 1033 rule stayed, is a SkyPoint integration even possible right now?

Yes. The integration runs on authorized interface analysis under the credit union's or the member's consent, which does not depend on the rule being in force. We shape the output to FDX-style account and transaction objects so it lines up with the standard if and when it settles for institutions this size.

Does the Wear OS / smartwatch surface limit what you can pull?

No. The watch surface only mirrors a balance and the last five transactions. The integration ignores that summary as a data source and pulls full accounts, history, transfers and statements from the primary member session.

Working with us on SkyPoint

The SkyPoint endpoint source ships from $300, billed only after it is in your hands and working to your satisfaction; if you would rather not run it yourself, the same integration is available as a hosted API you call and pay per call, with nothing upfront. A typical build is one to two weeks. You give us the app name and what you need from its data — the consenting access and the compliance posture are arranged with you as part of the engagement, not a hurdle you clear first. Send that to our contact page and we will scope it. If you want to compare this against other credit-union targets first, the OpenBanking Studio home page is the place to start.