Pulling member records out of AirTeller, First Education FCU's mobile front end

The Android package com.firstedfcu.grip and First Education FCU's own credit-union lexicon both name AirTeller as a Jack Henry product, accessed under the credit union's brand. So an integration against AirTeller is, in practice, an integration against a small slice of Jack Henry's mobile stack as configured for a roughly $84M-asset Wyoming credit union — with a Symitar/Episys core sitting behind it. The reachable surface for any one consenting member is whatever they see in the app: accounts, transactions with their own annotations, monthly statements, internal transfers, iPay bill-pay, card controls.

What a member can see — and therefore what we can map

The table below names every data domain we have located inside AirTeller for a First Education FCU member. The granularity column reflects what is actually visible in the app's own screens, not a generic banking schema.

Authorized routes to that data

Three routes apply here. We do not list any vendor-API route — that question is not part of the conversation. Every route below assumes the member's own consent and a small amount of paperwork between us, the integrator, and the credit union where the use case calls for it.

Member-authorized interface integration

This is the spine. The member logs in to AirTeller as usual; we analyse the HTTPS calls the app makes during session bootstrap, account list, transaction pull, statement fetch and iPay payee lookup, and reimplement the read-side as a clean Python or Node module. Effort: roughly one to two calendar weeks for the read surface. Durability: high — the Jack Henry frontend is stable across releases — with a small re-validation pass wired in so a Banno update is caught early.

Statement parsing as historical backfill

The mobile feed returns a useful window of recent transactions; for anything longer (underwriting decisions, multi-year tax exports), we fetch monthly statement PDFs from the same authorized session and parse them. The two feeds reconcile on date, amount and description.

Credentials-on-file recurring sync

Where the integrator already has the member's consent and credentials and wants a recurring pull instead of a one-shot, we wrap the analysed protocol in a worker that logs in, syncs, and stores nothing it doesn't need. Most "connect your bank" use cases collapse to this in practice.

For the typical brief that arrives — a fintech that wants its First Education FCU member's balances and transactions visible alongside the member's accounts at a larger bank — the first route is the one we recommend, with statement parsing reserved for the rare ask that needs more than the live window.

A worked example — the calls a single member's pull actually makes

The snippet below is illustrative; the exact field names and host are confirmed against the live app during the build. The intent is to show the shape: a session-bearer login, an account list, a per-account transaction page, and the statement index — each step matching what the AirTeller app does for the same member.

# Illustrative — exact endpoint paths and field names confirmed during the build.
import requests

s = requests.Session()
s.post(
    "https://airteller.example/auth/v1/login",
    json={
        "username": MEMBER_USER,
        "password": MEMBER_PASS,
        "device_id": REGISTERED_DEVICE_FINGERPRINT,
    },
)
# Session bearer is set via Set-Cookie; the mobile client re-uses it
# until the refresh window closes, at which point we re-bootstrap.

accounts = s.get("https://airteller.example/api/v1/accounts").json()

for acct in accounts["accounts"]:
    txns = s.get(
        f"https://airteller.example/api/v1/accounts/{acct['id']}/transactions",
        params={"from": "2026-01-01", "to": "2026-05-21"},
    ).json()
    # Each txn row: date, amount, description, posted/pending,
    # member_tag, member_note, receipt_uri.

statements = s.get(
    "https://airteller.example/api/v1/statements"
).json()
# statements[i]: {period, pdf_url, generated_at}

payees = s.get(
    "https://airteller.example/api/v1/billpay/payees"
).json()
# Join scheduled payments back to transactions on date + amount + payee.

Note the receipt_uri field. AirTeller's own listing names "photos of receipts and checks" as a transaction-level annotation, so an integrator wanting a Shoeboxed-style receipt feed gets it from this same call — no separate document service.

What you receive at the end of the build

For an AirTeller engagement the package is concrete:

• An OpenAPI 3.1 spec covering every endpoint we mapped — login, refresh, accounts, transactions, statements, transfers, iPay payees, scheduled payments, card-control reads. Generated from the live mapping, not hand-written from a template.
• A protocol & auth-flow report describing the login chain — username/password, device fingerprint, the bearer-cookie lifetime, the refresh path — written so an engineer who never saw the app can re-implement it.
• Runnable Python (or Node, on request) for the read-side endpoints, with a small async worker for recurring pulls.
• Automated tests against recorded fixtures, plus a daily smoke test for the production path so a Jack Henry update is caught the morning it ships.
• Interface documentation: each domain in the table above, with the request/response shape, the field semantics, and the joins we use to merge iPay and posted transactions.
• A short compliance & data-retention note fitted to the integrator's stack — what to log, what not to store, how consent revocation is honoured.

Member consent and the US data-rights picture for this credit union

NCUA supervises First Education FCU as a federally chartered credit union; that supervision sets the regulatory floor under which the member's data is held. The actual authorization for the build is the member's own — written consent to access their own account on their behalf, plus an NDA between us and the integrator when one is requested. We ride the member's session; we do not bypass it.

The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is occasionally raised in conversations like this. As things stand it is not the governing US framework: it was finalized in late 2024, enjoined by the Eastern District of Kentucky in October 2025, and reopened by the CFPB through an August 2025 advance notice of proposed rulemaking. Small federally chartered credit unions of First Education's asset size would be at the back of any phased compliance timeline if the rule returns in something like its original form. We watch the rulemaking; we do not build the integration on the assumption that §1033 will land in any particular shape, because the member's authorization is the basis we can rely on today.

Engineering details we account for on a Banno-skinned credit-union app

1. Mixed share-product handling. First Education's product set, per its services page, spans share savings, share drafts, certificates, IRAs and several loan types. The underlying core exposes those with different identifier shapes; we collapse them into one normalized account record so a downstream system sees one list rather than five.
2. Session refresh, not session drop. The mobile bearer's refresh window is short and silent — long syncs can hit a 401 mid-pull. The worker detects the 401, re-bootstraps with the member's credentials we hold under consent, and resumes from the last successful page, so the integrator never sees a half-finished feed.
3. iPay join. Bill pay sits behind a separate endpoint set reached through AirTeller, exactly as the credit union's lexicon describes. We pull payee records and scheduled payments from that path and join them to posted transactions on date, amount and payee match, so the integrator gets one combined ledger rather than two disjoint feeds.
4. Re-validation in maintenance. Jack Henry rolls platform updates periodically. We ship a small daily smoke test against the mapped endpoints so a field-name change or a routing tweak is flagged before a customer notices anything wrong.

How the engagement runs

An AirTeller build typically lands within one to two calendar weeks of kickoff. The surface a single member sees is not large, the Jack Henry frontend is stable, and we have already mapped neighbouring credit-union apps that sit on the same platform.

Source-code delivery starts at $300. You receive the OpenAPI spec, the protocol report, the runnable Python and the test suite as one package, and you pay only after delivery once the build is doing what you asked it to do. The pay-per-call hosted API is the other model: we run the integration on our infrastructure, you call our endpoint per member, and you pay only for the calls you make — no upfront fee, no minimum.

Tell us which surfaces you actually need — only balances? balances plus transactions and statements? card controls as well? — and which model fits your stack, and we will scope and start. Contact OpenBanking Studio →

Where an AirTeller integration tends to land in practice

• A PFM aggregator that wants its user's First Education FCU accounts visible next to the user's checking at a larger bank, with transactions reconciled on a single ledger.
• An accounting plug-in that imports tagged AirTeller transactions and the receipt photos the member already attached, so a freelancer member doesn't re-photograph the same receipts inside a second app.
• A consumer-lending partner pulling the last twelve months of share-draft activity for a debt-to-income decision, with the member's consent and a clean cut-off on revocation.
• A treasury or finance ops tool inside an employer that the credit union serves, surfacing scheduled iPay payments alongside the member's payroll deposits.

Screens we map against

Click a tile to enlarge. These are the AirTeller screens as the member sees them — the source of the field names in the table above.

Sources checked, and when

Between 19 and 21 May 2026 we read: First Education FCU's own mobile-banking page and credit-union lexicon (which names AirTeller as a Jack Henry product and iPay as accessed through AirTeller); Jack Henry's SymXchange developer documentation; and the CFPB's August 2025 Federal Register notice reopening §1033 for reconsideration. App-level facts come from the Play Store listing for com.firstedfcu.grip.

OpenBanking Studio integration desk — mapping reviewed 2026-05-21.

Other small-CU mobile portals in roughly the same shape

The apps below sit in the same neighbourhood as AirTeller — small to mid-sized US credit unions running a branded mobile portal over a vendor core. Naming them is not a ranking, it is a map of where a "connect every credit union" integration usually lands.

• Aeroquip Credit Union Mobile — single-employer-aligned CU mobile portal with a similar account/transaction/statement surface.
• Marine Credit Union Mobile — Wisconsin community CU on a comparable mobile platform with transaction tagging.
• Launch Credit Union Mobile — Florida CU whose member surface lines up closely with AirTeller's.
• Kinecta Mobile Banking — larger California CU with a richer card-controls panel but the same data shape.
• Arrowhead Mobile Banking — California CU mobile portal with statements and bill pay reachable through the same model.
• American First Mobile — California CU app, transaction history and transfers as the lead surfaces.
• Abilene Teachers FCU Mobile — Texas educator-aligned CU, equivalent member-data set.
• Radiant Credit Union Mobile — Florida CU on a similar vendor stack.
• Southland CU — California CU with bill pay and card-management features in the same place.

Questions integrators tend to ask about AirTeller

Does this AirTeller build sit on Jack Henry's Banno platform behind the scenes?

Yes. First Education FCU's own credit-union lexicon names AirTeller as a JHA product, and the Android package com.firstedfcu.grip is the brand the credit union puts on the Jack Henry mobile stack. Internally that means a Banno-style mobile frontend over a Symitar/Episys core; the SymXchange web-services layer is how Jack Henry products and approved third parties already reach the same records we map for you, just from the institution side.

Can the integration pull the tags, notes and receipt photos members attach to transactions?

Yes — those annotations are stored on the transaction record itself, as the app's own listing describes (tags, notes, photos of receipts and checks). When we map the transaction endpoint we return them in the same row as date, amount and description, so a downstream system gets the receipt URI without a second call.

How does bill pay come back, and is it joinable to the transaction feed?

Bill pay on AirTeller is iPay, which the credit union's lexicon describes as accessed through AirTeller. It sits behind a separate endpoint set; we pull payee records and scheduled payments from that path and join them to posted transactions on date, amount and payee match, so the integrator sees one combined ledger rather than two disjoint feeds.

Is the CFPB §1033 rule a hard requirement we should plan an AirTeller integration around?

Not as it stands. The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) was finalized in late 2024, then enjoined and reopened for reconsideration through the agency's August 2025 advance notice. We watch the rulemaking — small federally chartered credit unions like First Education would be at the back of any phased compliance timeline if the rule returns — but we anchor the build on the member's own authorization, which is the dependable basis today regardless of where §1033 lands.