Building an authorized data pipe into Peoples Advantage FCU

The Android package id org.peoplesadvfcu.grip is the first useful clue here. Peoples Advantage FCU runs its mobile app on a shared white-label shell — the .grip suffix shows up across several small US credit unions (OUR Credit Union, Family Security CU, CME FCU, Credit Union of the Rockies), each with their own brand, member field and member-portal hostname layered on the same shell. So the integration question splits in two: what does the shell expose, and what is specific to this credit union's slice of it.

Bottom line for someone budgeting this: it's a small-CU shape we've mapped before. Two pieces are worth flagging upfront — the aggregation panel (because it's not really PAFCU's data, see below) and the GRIP shell (because once the protocol notes exist, a sibling .grip credit union is a re-validation, not a rebuild). We'd route the build through the authenticated member portal under the member's own authorization, with the deliverable being runnable source plus the protocol report.

Where the member data actually lives

The app describes itself, in its own words, as an aggregator of the member's financial accounts plus all the usual core-banking surfaces. Mapped to integration targets:

Routes to that data we'd actually use

1. Authorized interface integration on the GRIP shell (the spine)

This is the route the rest of the build hangs off. We take the member's own credentials, log into my.peoplesadvfcu.org the same way the GRIP app does, and call the JSON endpoints the authenticated session exposes. Effort: a one-to-two week pass to nail down the auth handshake, the OTP step, the account/transaction/statement shapes and the aggregation panel's separate data flow. Durability: stable while the GRIP shell and member-portal front end stay on the same version line; the maintenance window includes a scripted re-run of the contract tests so a shell upgrade surfaces as a CI failure rather than as broken production traffic.

2. User-consented credential access through the member portal

Same surface, different posture: the integration runs as the member, with the member's explicit on-record consent and revocation. For a small CU like this — where most integration requests come from a single member household, a small business that banks here, or an advisor with one or two client members — this is often the cleanest legal framing. We arrange the consent flow and the revocation surface as part of the build.

3. Native export (PDF statements and per-account CSV)

The member can download monthly statement PDFs and per-account transaction CSVs from the portal today. We use this as the historical backfill behind the live route — pull the last 18–24 months in one pass, then keep the live route incremental. It also gives us a checksum: live data parsed from JSON should reconcile against the same month's PDF.

4. Forward-compatible standardized route

The §1033 path is currently unsettled (see the consent section below). We design the spec so that when a standardized credit-union data-sharing surface does land, swapping the underlying transport is a configuration change, not a rewrite.

In practice we'd lean on route 1 for the live data, fall back to route 3 for the historical backfill, frame the engagement under route 2's member-consent posture, and leave route 4 sitting as a forward hook in the spec. For a credit union this size the live + backfill split is what keeps the integration usable on day one instead of waiting on a multi-year regulatory path to land.

What lands in your repo

• OpenAPI 3 spec covering the member surfaces above — typed schemas, error envelopes, the separate aggregation-panel namespace, and a clear note on which fields originate at PAFCU vs. at the third-party aggregator.
• Runnable source in Python (httpx) and Node.js (undici/axios) for the live calls: login + OTP, native accounts, transactions with member metadata, linked-external accounts, bill-pay history, statement download, card status. Each module is a thin client your code can import — not a generated stub.
• Protocol & auth-flow report documenting the GRIP shell's session shape, CSRF/cookie chain, OTP step, refresh behavior, and the specific PAFCU-side parts that differ from a generic .grip sibling. This is the document that makes the build maintainable.
• Automated tests — contract tests against canned fixtures, plus a live-mode runner that exercises a consenting test member's account so you catch upstream changes.
• Interface documentation: a short developer guide your team uses to wire the client into your product, with the consent-record schema and the revocation handler called out.
• Compliance and retention notes tied to NCUA Regulation P expectations and the member's consent scope.

A worked example

Shape illustrative; the exact field names and the OTP branch are confirmed against a consenting test member during the build, not asserted from outside the engagement.

import httpx

BASE = "https://my.peoplesadvfcu.org"

def login(username: str, password: str) -> dict:
    """The member portal serves the same authenticated session
       the GRIP mobile app posts to."""
    s = httpx.Client(headers={"User-Agent": "PAFCU-Mobile/x.y.z"})
    s.get(f"{BASE}/login")                      # CSRF + session cookies
    r = s.post(f"{BASE}/auth/session",
               json={"username": username, "password": password})
    r.raise_for_status()
    body = r.json()
    if body.get("step") == "mfa":
        # out-of-band device verification — handed off to the
        # consent flow we build alongside this client
        return {"status": "mfa_required", "session": s, "challenge": body["challenge"]}
    return {"status": "ok", "session": s}

def native_accounts(s: httpx.Client) -> list[dict]:
    """Shares and loans the member holds at PAFCU."""
    return s.get(f"{BASE}/api/accounts").json()["accounts"]

def transactions(s: httpx.Client, account_id: str, since: str) -> list[dict]:
    """Per-transaction records including member-added tags, notes
       and any check/receipt image references."""
    return s.get(f"{BASE}/api/accounts/{account_id}/transactions",
                 params={"since": since}).json()["transactions"]

def linked_external(s: httpx.Client) -> list[dict]:
    """The aggregation panel. These accounts resolve via the
       third-party aggregator the credit union contracts with,
       not from PAFCU's core directly — keep them in a separate
       namespace in the normalized output."""
    return s.get(f"{BASE}/api/aggregation/linked").json()["linked"]

The normalized output we'd hand back looks roughly like this — the split between source: "pafcu" and source: "aggregator" matters because it tells your downstream code which records to trust as authoritative and which are refreshed on the aggregator's schedule:

{
  "member_id": "<opaque>",
  "accounts": [
    {"source": "pafcu", "type": "share",   "balance": 0.00, "currency": "USD", "id": "****1234"},
    {"source": "pafcu", "type": "loan",    "balance": 0.00, "currency": "USD", "id": "****5678"}
  ],
  "linked_external": [
    {"source": "aggregator", "institution": "<name>", "type": "checking",
     "balance": 0.00, "as_of": "2026-05-26T00:00:00Z"}
  ],
  "consent": {
    "granted_at": "2026-05-26T00:00:00Z",
    "scope": ["accounts.read", "transactions.read", "statements.read"],
    "revocable_at": "https://<your-app>/consent/<id>"
  }
}

Things the build accounts for

A few specifics about Peoples Advantage FCU that shape how we put the integration together:

• The aggregation panel is not PAFCU's data. When a member links a Chase checking account inside the app, that record resolves through a third-party aggregator the credit union contracts with — PAFCU is the relying party, not the source of truth. We design two namespaces in the normalized output and two consent records, so your downstream code never confuses the two surfaces and so a member who revokes the external linkage doesn't also revoke their PAFCU surface.
• The GRIP shell is shared, the brand layer isn't. Most of the protocol scaffolding ports across to a sibling .grip credit union; the member-portal hostname, the OTP delivery channel, the branch and account-type labels, and any custom alert preferences are PAFCU-specific. The protocol report calls out which is which, so a future build against, say, CMEFCU is a re-validation pass on a known scaffold rather than a fresh reverse-engineering job.
• Member-side metadata is part of the value. The app lets members add tags, notes and photos of receipts and checks to individual transactions. That's user-created data sitting on top of the transaction surface; we expose it in the spec because most downstream uses (bookkeeping import, household PFM) lose half their value if it gets dropped.
• Shell upgrades show up in CI before they show up in traffic. Small institutions on shared shells get version-bumped on a cadence we don't control. The maintenance window covers a scripted re-run of the contract tests against a consenting test member, so a shell upgrade surfaces as a failed CI build rather than as production breakage at 2am.
• Branch quirks land in the data, not in the API. PAFCU runs branches plus a mobile unit that visits Hopewell on Mondays per its own materials; transactions originated through that channel carry the branch label like any other. We surface the label as-is and don't try to normalize it across the four physical and one mobile locations.

Access and onboarding — a consenting test member, sandbox arrangements, NDA — are arranged with you during the kick-off, not pre-set as something you have to assemble before we'll start.

Member consent & Reg P, with §1033 as the open variable

For Peoples Advantage FCU the load-bearing basis on day one is the member's own authorization. A member can ask us to access her own accounts on her behalf — the same posture the GRIP app's own aggregation panel already takes when she links an external bank inside it. NCUA Regulation P frames how a credit union of this size handles information sharing with third parties and the notices and opt-outs members get; the integration stays inside that frame, logs consent and revocation, and minimizes what's stored.

The Personal Financial Data Rights rule that would, in some future version, hand small credit unions like PAFCU a standardized member-permissioned data surface is currently back in agency reconsideration and not in force, so we don't anchor the build to a moving deadline or to specific obligations that may not survive the rewrite. The dependable basis is the member, today. If and when a standardized surface lands for an institution this size, the spec has a transport slot waiting for it.

How we'd price this one

The deliverable shape is the same regardless of how you pay — the OpenAPI spec for the PAFCU member surfaces, runnable Python and Node source for login, accounts, transactions, the aggregation panel and statements, the GRIP-shell protocol notes, and an automated contract-test suite. Source-code delivery starts at $300, billed only after we hand the work over and you've signed off on the handover. Or call our hosted endpoints and pay per call, no upfront fee. Cycle is one to two weeks. Send us the use case and we'll come back with which one fits better and a date.

Adjacent credit-union apps in the same integration shape

These are real apps an integrator working in the same problem space would see alongside Peoples Advantage FCU. Listed for keyword and ecosystem context, not as ranking or comparison — each is a separate institution with its own member data and its own posture.

• VACU Mobile — Virginia Credit Union's app. The largest VA credit union, overlapping field of membership in the Richmond/Petersburg corridor; similar core surfaces at a much larger scale.
• 1st Advantage Federal Credit Union — a Virginia federal credit union with comparable mobile-banking surfaces; relevant when an integration spans both institutions for a household.
• UVA Community Credit Union — central Virginia community CU; the same shape of authenticated member portal plus mobile app.
• Apple FCU — northern Virginia federal credit union; relevant for advisors with clients across the Richmond and DC-metro corridors.
• Self-Help Federal Credit Union — multi-state CU including Virginia; different scale, similar member-data surfaces.
• OUR Credit Union Mobile — a sibling on the same GRIP white-label shell (org.ourcuonline.grip); useful comparison point because the underlying protocol scaffold is shared.
• My FSCU — Family Security CU's app on the GRIP shell (com.myfscu.grip); same shared scaffold, different field of membership.
• CMEFCU Mobile — another GRIP sibling (org.cmefcu.grip).
• Credit Union of the Rockies — also GRIP (org.curockies.grip); useful evidence the shell is in production at multiple institutions.

Questions you'd ask us first

If we later switch to another credit union built on the same GRIP shell, how much of the integration carries over?

Most of the protocol scaffolding ports across — the auth handshake, the cookie/session shape, the JSON envelope on the member endpoints, and our contract-test suite. The brand-specific pieces (member-portal hostname, OTP delivery, branch/account labels) get re-pointed. We say so plainly in the protocol report so a sibling .grip credit union build is mostly a re-validation pass, not a rewrite.

The aggregation feature pulls accounts from other banks. Whose data flow is that, technically?

That panel almost always sits on a third-party data aggregator the credit union contracts with — Peoples Advantage FCU is the relying party, not the data source for the linked external accounts. We separate the two in the spec: native PAFCU shares and loans come from the member portal directly, and the linked external accounts come back through whichever aggregator the app is wired to. The integration treats them as two surfaces with two consent records.

How do you read the CFPB 1033 situation for a credit union this small?

We treat it as the open variable, not the basis of the build. The rule is back in agency reconsideration and is not currently enforceable against an institution of PAFCU's size — public directories put it in the ~$99M asset range — so there's nothing concrete to design against on that side today. The basis we actually rely on is the member's own authorization under NCUA Regulation P, and the spec has a transport slot kept open for whatever standardized credit-union surface eventually lands.

Where these notes come from

For this brief we walked the Peoples Advantage FCU online-services page, the GRIP-suffix package listing on the Play Store, the member-portal hostname, the NCUA's Regulation P guidance and account-aggregation letter, and the current state of the CFPB Personal Financial Data Rights rule and its reconsideration docket. We did not assert anything about an institutional API surface; statements about asset size and member count are taken from public credit-union directories and hedged accordingly. Primary sources:

• Peoples Advantage FCU — Online and Mobile Banking
• Google Play listing — org.peoplesadvfcu.grip
• CFPB — Personal Financial Data Rights Reconsideration
• NCUA — Account Aggregation Services guidance

Mapping by the OpenBanking Studio integration desk, May 2026.

Mapping reviewed 2026-05-26.