Getting structured data out of Meritrust Colorado, the merged Premier Members app

On August 1, 2025, Premier Members Credit Union merged into Meritrust Credit Union, and the Colorado banking app many members still tap open — listed on the App Store under id 634529900 and shipping on Android as com.premiermemberscu.premiermemberscu, per its store listings — now carries the Meritrust Colorado name. The merged credit union kept the Meritrust name, took on a Colorado state charter in place of its old federal one, and reports its headquarters in Broomfield; the credit unions describe a combined book of roughly 200,000 members and close to $4 billion in assets spread across Kansas and Colorado. For anyone reading a member's account data programmatically, that history is the whole story. There are two legacy membership bases being stitched into one, and the app's front end is a moving target while it happens.

What a third party actually wants here sits behind the member login: balances, categorized activity, savings goals, card state. None of that lives on the marketing site. The dependable way to reach it is the member's own authorization, and that is the basis we build on. The rest of this page maps what the app holds, the authorized routes to each surface, and the source we hand over.

Bottom line: the data you care about is real, structured, and per-member, but it is gated by a sign-in and is in motion because of the merger. The build that survives that is one anchored to member consent and tested to notice when the app changes shape.

What sits behind a member sign-in

The surfaces below come straight from how the app describes itself on the store and how its screens are laid out. Granularity is what an integrator can realistically expect per record once a consented session is live.

Authorized ways to reach the data

Three routes genuinely apply to this app, plus a quick batch fallback. Each is something we stand up with you during the build — access and consent capture are part of the work, not a hoop you clear first.

Member-consented session

The member authorizes access and we operate the consented session: read the surfaces above, refresh the token, honor revocation. Reachable: everything behind the login. Effort is moderate; durability is high while consent stands and depends on the member's re-auth cadence.

FDX-aligned consumer-permissioned data

Where a member's accounts are already reachable over the US consumer-permissioned rails — the Financial Data Exchange schema the market is consolidating on — we map to that standard rather than re-deriving it. Reachable: standardized account and transaction data. Effort is lower when a connection already exists, more when we build the mapping; durability tracks the standard.

Authorized interface and protocol analysis

Under your authorization we document the app's own request and response traffic and its auth handshake, then build a client that speaks it. Reachable: any surface the app itself renders, including categories, savings goals, and card state. Effort is higher and the client is tied to the app version — which matters here, because the post-merger front end will change.

Native export

Statement and transaction downloads the member can pull, parsed into structured records. Coarse and batch-shaped, but the fast way to backfill older history.

My recommendation for this one is to build on the member-consented session. The data most teams ask about — categorized transactions, savings-goal progress, card state — exists only behind the member login, and a consent stays valid no matter which legacy core ends up serving that member once the books are fully merged. If a member's accounts are already exposed over the FDX rails, we map straight to that schema and skip the heavier client work. The protocol-level client earns its place only for a surface the app shows that nothing else reaches, and a statement parse covers history.

What lands at handover

Everything below is built against this app's actual surfaces, not a template.

• An OpenAPI/Swagger spec covering the normalized account, balance, transaction, savings-goal, bill-pay and card-state objects.
• A protocol and auth-flow report: the device-registration to credential to token chain, token refresh, and the step-up MFA the app triggers on a new device (Touch ID and Face ID map to a device-bound credential, not a separate data path).
• Runnable source in Python or Node.js for login, the account list, transaction pulls, savings-goal reads and card-state reads.
• Automated tests, including contract tests written to catch a post-merger front-end change before it reaches you.
• Interface documentation plus a normalized schema, so a Colorado member and a Kansas member resolve to one shape.
• Compliance and data-retention guidance: consent records, access logging, data minimization, and an NDA where the work needs one.

The token and account pull, sketched

Illustrative shapes only. Exact paths, field names and the precise MFA trigger are confirmed against a consented session during the build — they are not published anywhere and this is not copied from a vendor doc.

# 1) Device-bound session. Biometric sign-in maps to a stored credential + step-up.
POST /auth/login
  { "username": "...", "password": "...", "deviceId": "<registered>" }
  -> 200 { "accessToken": "...", "expiresIn": 900, "mfaRequired": false }
  -> 401 { "mfaRequired": true, "challenge": "otp" }   # new device / step-up

# 2) Account list — the snapshot the app paints on open.
GET /accounts                 Authorization: Bearer <accessToken>
  -> [ { "id": "...", "type": "share|checking|loan|card",
         "nickname": "...", "available": 0.00, "current": 0.00 } ]

# 3) Activity for one account (statement / transaction history).
GET /accounts/{id}/transactions?from=2026-01-01&to=2026-03-31
  -> [ { "postedDate": "...", "amount": -42.10, "description": "...",
         "category": "...", "pending": false } ]

# 4) Card state is read-only unless a write capability is separately authorized.
GET /cards/{id}/state         -> { "locked": false }

# Handling notes:
#   401 mfaRequired  -> run the step-up, then retry with the refreshed token
#   429              -> back off; the app paces its own polling, so we mirror that
#   token near expiry-> refresh ahead of the call rather than on a failure
      

Where teams wire this in

• A budgeting or PFM app pulling balances and categorized transactions for a member who banks at Meritrust Colorado, with savings-goal progress surfaced alongside.
• A bookkeeping tool syncing a small-business member's checking activity into its ledger on a consented, scheduled basis.
• A lender reading consented transaction history for income and affordability checks, no screen-scraping of the member's password held by the lender.
• An internal data team backfilling member activity into a warehouse after the merger, where Colorado and Kansas records need to land in one schema.

Member consent, a state charter, and the rule that has not switched on

Meritrust is now a Colorado state-chartered credit union — it dropped its federal charter in the merger, per the merger announcement — so its data-sharing posture answers to Colorado's Division of Financial Services and to NCUA share-insurance rules, not to any single federal open-banking mandate that is actually in force. The federal Personal Financial Data Rights rule that would have set one common access standard is, at the moment, not something this credit union has to build against: a court has paused enforcement and the CFPB is rewriting it (its reconsideration notice was published in August 2025). So the access we rely on is the member's own authorization, which holds regardless of where that rule lands. Consent is scoped to the surfaces you actually need, carries an expiry and a revocation path, and we record it. We log access, keep data to the minimum the use case requires, and work under an NDA where the engagement calls for one.

Engineering realities we plan around

These are the two things that make this app its own job rather than a generic credit-union build.

A front end mid-migration

The Colorado app is the old Premier Members client carrying a new name, and it is a strong candidate to migrate onto a shared post-merger platform as the two institutions consolidate. We build a contract-test layer that flags the day the app's responses drift, so a front-end migration shows up as a scheduled update on our side rather than a feed that quietly goes dark. We design access to be re-pointed at the new platform without re-architecting the consumer.

Two legacy books under one name

A member who joined through Premier Members in Colorado and a member who joined through Meritrust in Kansas may still be served by different legacy cores during consolidation. We map the integration to whichever core actually backs a given member's login and normalize the output so both resolve to one schema. Access is arranged with you during onboarding — the build runs against a consenting account or a sponsor sandbox, and we scope it read-only by default, treating any state-changing endpoint (a card freeze, a transfer) as a separate, explicitly authorized capability.

Pricing and how delivery runs

A working Meritrust Colorado integration runs about one to two weeks once there is a consenting account to build against. You can take it as delivered source code — the runnable API source plus the auth-flow report, the spec, the tests and the docs, from $300, billed only after we hand it over and you are satisfied — or skip hosting it yourself and call our endpoints on a pay-per-call basis with nothing upfront. Either way you give us the app name and what you want out of its data; we handle access, consent capture and the compliance paperwork as part of the build. Tell us what you are after on the contact page.

Screens we mapped

The store screenshots we worked from while laying out the surfaces above. Select one to enlarge.

Other Colorado and Kansas member apps nearby

Same category, named for context and for anyone scoping a unified integration across more than one institution. No ranking, no endorsement.

• Ent Credit Union — Colorado's largest credit union; its app holds the same account, transfer and card-control data behind a member login.
• Bellco Credit Union — a Denver mainstay whose app surfaces balances, transactions and bill pay per member.
• Elevations Credit Union — Boulder-rooted, with the usual authenticated balances, activity and transfer surfaces.
• Canvas Credit Union — one of Colorado's larger credit unions; member portal data of the same shape.
• Westerra Credit Union — its consumer and business apps expose balances, history, transfers, bill pay and check deposit.
• Credit Union of Colorado — statewide membership with account, payment and card data behind sign-in.
• Partner Colorado Credit Union — a smaller Colorado institution with comparable member-portal surfaces.
• Meritrust Credit Union (Kansas) — the other half of the merged book, on its own app domain; the same account and transaction data, possibly on a different core during consolidation.

How this mapping came together

Checked in June 2026 against the credit unions' own merger materials, the app's store listing and the current federal data-rights status. The merger facts (effective date, charter change, member and asset figures, Broomfield headquarters) come from the announcement; the §1033 status from the CFPB's own reconsideration page and contemporaneous legal coverage of the injunction.

• GoWest Association — merger approval announcement (Jul 29, 2025)
• Premier Members CU — merger press release (PDF)
• App Store — Meritrust Colorado listing (id 634529900)
• CFPB — Personal Financial Data Rights reconsideration

Researched and written at the OpenBanking Studio integration desk — June 2026.

Questions integrators raise about Meritrust Colorado

We picked up members from both the old Premier Members book and the Kansas Meritrust book. Can one integration read both?

Yes. Since the August 2025 merger the two membership bases sit under one Meritrust Credit Union, though they may still be served by separate legacy cores while consolidation runs. We map the integration to whichever core actually backs a given member's login, then normalize the output so a Colorado member and a Kansas member look identical to your application.

Which surfaces from the app can you turn into a clean feed?

The ones a member sees after signing in: balances and the activity snapshot, posted and pending transactions with the app's own spending categories, savings-goal and budget progress, bill-pay payees and scheduled payments, transfer history, and debit and credit card state. Freezing or reactivating a card is a write action, so we expose it only when you ask and it is separately authorized.

Meritrust is now a Colorado state-chartered credit union. Who regulates the data sharing, and do we wait on the federal open-banking rule?

Day to day the credit union answers to Colorado's Division of Financial Services and to NCUA share-insurance rules. The federal Personal Financial Data Rights rule that would set one common access standard is paused by a court and back in rewriting at the CFPB, so it is not a switch you wait on. The access we build on is the member's own authorization, which holds either way.

When the apps finish merging onto one platform, does our feed break?

That is the main thing we design against here. The Colorado app is likely to migrate onto a shared post-merger front end, so we ship contract tests that flag the day responses drift. A platform change then becomes a scheduled update we handle, not a silent outage.