Member data inside Abilene Teachers FCU Mobile, and the route we use to reach it

The Android build ships as com.ifs.banking.fiid3630, per its Google Play listing — the same digital-banking client a few dozen other US credit unions run, with Abilene Teachers FCU's institution number, 3630, fixed in the package name. The iOS edition is App Store id 390569540, per its App Store listing. So the integration question here is not really about one app. It is about one tenant on a shared multi-institution backend, and the data a member sees once that backend has matched them to credit union 3630. Abilene Teachers Federal Credit Union is a Texas school-employee credit union, chartered in 1950 per its own materials, with roughly 50,000 members and about $650 million in assets by public credit-union directory figures. The app is free to members enrolled in online banking.

Member data the app puts in front of a logged-in user

Every row below is a surface the credit union or the store listing names directly. Granularity reflects what a member can see in the app, not a guess at the wire format — field shapes are confirmed during the build.

Getting at the data: the routes that genuinely apply

1 — Authorized protocol integration of the member session

The app authenticates a member to the shared backend, scoped to institution 3630, then reads balances, history, transfers, bill pay, offers and card-control state. We map that exchange and rebuild it as a clean server-side client. Everything the member sees is reachable. Effort is medium; durability is tied to the platform client, so the build includes a re-validation step for when the app updates. Access is arranged with you during onboarding — a consenting member account or test credentials for institution 3630.

2 — Consumer-permissioned aggregation

For balances and transactions on ATFCU accounts, FDX-standard data sharing through the established US aggregation networks the credit union already connects to is the durable read path. Lower effort, high durability, consent-scoped, and maintained by the network rather than by us. It does not cover bill-pay payees, card controls or offer activation.

3 — Native export as backfill

The digital-banking web channel produces e-statements and transaction extracts, and the Money Management view exports aggregated positions. Low effort, useful for history backfill and reconciliation, weaker for anything near real time.

4 — Member-authorized credential access

For the surfaces aggregation skips — payee lists, card on/off, offer activation — a member-authorized session covers the gap. Scope is held to the domains the project needs.

For this app the protocol integration is the backbone because it is the only route that reaches the full surface, with consumer-permissioned aggregation carrying the steady balance and transaction load and native export filling history. We would say so plainly in the kickoff call and size each route to the data you actually need.

What a session against institution 3630 looks like

Illustrative shape, not a published contract — exact endpoints, field names and the multi-factor step are confirmed during the build. The detail that matters is the institution id threading every call.

POST /ifs/auth/login
{
  "fiId": "3630",
  "username": "<member>",
  "credential": "<secret>",
  "deviceId": "<bound-device>"
}
-> 200 { "session": "<token>", "mfaRequired": true, "mfaChannels": ["sms","app"] }

POST /ifs/auth/mfa            # answer the challenge, exchange for a full session
{ "fiId": "3630", "session": "<token>", "otp": "<code>" }
-> 200 { "session": "<full-token>", "expiresIn": 900 }

GET  /ifs/accounts?fiId=3630
Authorization: Bearer <full-token>
-> 200 [ { "acctId":"S0","type":"share","desc":"Regular Savings",
           "balance":1842.55,"available":1842.55,"currency":"USD" },
         { "acctId":"L4","type":"loan","desc":"Auto Loan",
           "balance":-9120.00,"nextDue":"2026-06-01" } ]

GET  /ifs/accounts/S0/history?fiId=3630&from=2026-04-01
-> 200 [ { "postedDate":"2026-04-03","amount":-54.20,
           "description":"ACH DEBIT","status":"posted" },
         { "postedDate":null,"amount":120.00,"status":"pending" } ]

# Handling that matters here:
#  401 + mfaRequired  -> re-run the MFA exchange, do not fail the sync
#  session expiry ~15m -> refresh before long history pulls
#  module-disabled     -> bill-pay/offers absent for this fiId; skip cleanly

What you get back from us

• An OpenAPI description of the normalized integration — accounts, history, transfers, bill-pay status, offers, card controls — with the institution id handled internally so callers never pass 3630.
• A protocol and auth-flow report: the login, multi-factor exchange, session token and refresh cadence as they behave for institution 3630, with the failure modes spelled out.
• Runnable source for the core reads and the transfer initiation path, in Python or Node.js, with retry and re-auth built in.
• Automated tests covering auth, MFA re-challenge, pending-versus-posted history, and a disabled-module case.
• Interface documentation a maintainer can act on, plus data-retention and consent-logging guidance scoped to a US credit union holding member NPI.

US data rights and how we keep access clean

This is an NCUA-insured federal credit union, so the relevant data-rights instrument is CFPB Section 1033, codified at 12 CFR Part 1033. It was finalized in late 2024, but the CFPB has it under reconsideration and a federal court has enjoined its enforcement, so its standardized data-access requirement is not being applied to an institution of this kind today. We do not assert the rule's tiered compliance dates as settled while it is being reopened. In practice US consumer-permissioned access rests on FDX-standard data sharing through the aggregation networks and on direct member-authorized access — which is exactly what routes 1, 2 and 4 use.

We operate authorized and consented only. Work runs against a consenting member account or institution-3630 test credentials arranged with you; consent is scoped to the data domains the project needs; revocation is honored; access is logged with consent records retained; member NPI is handled with GLBA-aware minimization; an NDA is in place where the engagement calls for one.

Engineering realities we plan around

These are specific to this app, and they are things we handle, not hurdles put on you.

• One client, many credit unions. The institution id 3630 scopes every call. We pin requests to it and map the modules ATFCU actually has switched on, so a configuration that is correct for a different institution on the same client cannot bleed into this one.
• Bill Pay is gated by prior enrollment. Pay Bills works only for members already enrolled in Bill Payment inside online banking. We design that surface to degrade cleanly when the consenting account is not enrolled, rather than letting it error the whole run; enrollment is sorted out with you at onboarding.
• Money Management data is second-hand. The outside-bank balances on that screen are aggregated by the credit union's own PFM, so we tag them PFM-sourced and keep them out of any path that needs an authoritative figure.
• The front end moves for everyone at once. Platform updates ship across all tenant credit unions together, so we keep a re-validation pass in the maintenance plan and catch a platform-wide change before it quietly breaks the feed.
• Multi-factor is part of the normal path. The credit union states it uses multiple-factor authentication, so we build the session around the challenge and the short token lifetime with an automatic re-auth, instead of treating an MFA prompt as a failure.

Where integrators put this data to work

• A bookkeeping tool syncing ATFCU share and loan transactions nightly into a ledger.
• A net-worth or budgeting app reading balances across a member's ATFCU accounts.
• A lender pulling member-consented transaction history for cash-flow underwriting.
• An accounts-payable system reading bill-pay payees and payment status.
• A treasury process moving funds between ATFCU and an outside account through the transfer surface.

Keeping the feed honest as the app changes

Balances are polled on an intraday cadence; transaction history is pulled with a settle window so pending items are not double-counted when they post. Transfer initiation is made idempotent so a retried call cannot send twice. History gaps are backfilled from e-statements. The integration alerts on two conditions a maintainer must see early: a multi-factor challenge that the re-auth path cannot clear, and a consent or session expiry on the aggregation side. Where aggregation and the direct session overlap, records are de-duplicated on posting date and amount.

Other credit-union apps in the same integration neighborhood

These are real apps in the same category, several on the very same shared client — which is the point: one integration pattern generalizes across them by changing the institution id.

• Truliant Federal Credit Union — member balances, transaction history and transfers for a large Carolinas credit union, on the same client family.
• Y-12 Federal Credit Union — accounts, bill pay, check deposit and loan payments behind a member login.
• Columbia Credit Union — Pacific Northwest member accounts, transfers and money movement.
• Affinity Federal Credit Union — balances, history and payments for a New Jersey based credit union.
• Connex Credit Union Mobile — Connecticut member accounts and transfers.
• WESTconsin Credit Union — Wisconsin member accounts, deposit and bill pay.
• Members Plus Credit Union — Massachusetts member balances and transaction history.
• Credit Union of Georgia — Georgia member accounts and money movement.
• WPCU Mobile Banking — Wright-Patt member accounts, transfers and deposit.
• Teachers Federal Credit Union — a larger teachers' credit union on the same client lineage, with the comparable account and payment surface.

Screens from the app

From the Google Play listing. Click to enlarge.

Questions integrators ask about this one

The app is the same codebase as a few dozen other credit unions. Does that change the work?

It helps and it sets the rules. The Android build is com.ifs.banking.fiid3630, a shared digital-banking client where the institution number, 3630, scopes every call to Abilene Teachers FCU. We pin the integration to that id and map the modules this credit union actually has enabled, because two institutions on the same client can expose different surfaces and different multi-factor styles.

Can you pull the outside-bank balances that ATFCU's Money Management screen shows, or only ATFCU accounts?

Both, with a label. ATFCU accounts are first-party and authoritative. The balances Money Management shows for outside banks and brokerages are themselves aggregated by the credit union's PFM, so we tag those as PFM-sourced rather than direct, and a downstream system should treat them as a secondary view, not a system of record.

With CFPB 1033 enforcement on hold, what authorized route actually works for a US credit union like this?

The rule's standardized data-access mandate is not being applied today, since it is under reconsideration and a federal court has enjoined the CFPB from enforcing it. US consumer-permissioned access runs on FDX-standard data sharing through the established aggregation networks and on direct member-authorized access. We build the protocol integration as the backbone and use consumer-permissioned aggregation for the steady balance and transaction read path.

How do mobile check deposit and Pay Bills enrollment affect what you can pull?

Check Deposit is a write-side action, so we treat it as an instruction surface with a status read, not a data feed. Pay Bills only works for members already enrolled in Bill Payment inside online banking, so we design the bill-pay surface to degrade cleanly when the consenting account is not enrolled instead of failing the whole sync. Enrollment and access are arranged with you during onboarding.

Sources and who checked them

This brief was put together on 2026-05-16 from the app's Google Play listing (package and feature set), the credit union's own digital-banking page (the named features: View Your Accounts, Transfer Money including outside-institution movement, Check Deposit, Pay Bills, Card Controls, Set Alerts, Money Management aggregation), and the CFPB's current rulemaking record for Personal Financial Data Rights. The shared-client observation comes from the package namespace appearing across many credit-union apps on the same store.

• Google Play — Abilene Teachers FCU Mobile (com.ifs.banking.fiid3630)
• Abilene Teachers FCU — Digital Banking features
• CFPB — Personal Financial Data Rights Reconsideration

Mapped by the OpenBanking Studio integration desk · 2026-05-16.

Engagement is simple. We can deliver the runnable integration source plus the OpenAPI description, the protocol and auth-flow report, tests and interface docs for a fixed fee from $300, billed after delivery once you have what you asked for and are satisfied; turnaround is one to two weeks. The alternative is to skip the build and call our hosted endpoints, paying only for the calls you make with nothing upfront. Tell us the app — Abilene Teachers FCU Mobile — and what you need out of its data; access and the compliance paperwork are arranged with you, not handed to you as a checklist. Start at /contact.html.