What it takes to integrate a Tinker FCU Business account

Tinker Federal Credit Union carries roughly $6.1 billion in assets and serves more than 470,000 members as of mid-2025, per NCUA call-report figures, which makes its business channel a real backend — payroll runs, vendor ACH, multi-account treasury — not a hobby ledger. Business members get a dedicated app, package com.tinkerfcu.tinkerfcu per its Play Store listing, separate from the consumer install. That separation matters for anyone integrating: the data and the entitlements differ from the personal app, and the work has to target the right one.

Account data the business app exposes to a logged-in owner

The credit union's own business-banking page and the app's store description describe a consolidated view of every TFCU account, recent transactions, transfers, mobile deposit, and a digital-payments module covering Bill Pay, ACH, direct deposit and pre-authorized payments. Mapped to what an integrator would consume:

Three ways into a TFCU Business account, and the one we'd run

Three routes genuinely apply here.

Member-consented connection

The business member authorizes the connection, and we drive the app's own authenticated session under that consent. This reaches the live balances, transaction history, transfer and payment surfaces — the widest coverage. Durable enough for production once the auth and refresh behaviour is mapped. Access and consent are arranged with the client as part of the engagement; the build runs against a consenting business account.

Authorized protocol analysis

Under the customer's authorization we capture and document the app's traffic — endpoints, token issue and refresh, request and response shapes, the MFA step-up. This is the work that makes the connection survive front-end changes; it is moderate effort up front and pays back in maintenance.

Native OFX / Direct Connect export

TFCU's business platform lists QuickBooks and Quicken Direct Connect, which gives a structured statement path in OFX. Lower effort, narrower scope — statement-grade history, not live action — and a clean fallback when that is all a ledger needs.

If we were scoping this today, the consented connection carries the integration, the protocol map is what keeps it alive when TFCU re-themes the portal, and the OFX path is the safety net for bookkeeping-grade data. We would build the first two and keep the third wired in.

What lands at the end of the build

Deliverables are tied to the surfaces above, not a generic checklist:

• An OpenAPI / Swagger specification for the balance, transaction, transfer and payment endpoints as observed for the business entitlement.
• A protocol and auth-flow report: the session token chain, refresh cadence, and how the multifactor step-up is handled across reconnects.
• Runnable source in Python or Node.js for the key endpoints — list accounts, pull transactions by date, read transfer and deposit status.
• Automated tests covering an owner session and a narrower employee session, so the role difference is verified rather than assumed.
• Interface documentation plus data-retention and consent-logging guidance fitted to a credit-union member relationship.

A request shape from the transaction surface

Illustrative — exact paths and field names are confirmed against the live business app during the build, under the member's authorization. The role guard at the bottom is the part most generic clients get wrong here.

# Placeholders. Real endpoints/fields are pinned during the build.

POST /auth/session            # consented login; MFA step-up handled
  -> { session_token, refresh_token, mfa_state }

GET  /accounts                # business entitlement, NOT the consumer profile
  Authorization: Bearer <session_token>
  -> [ { account_id, nickname, type:"business_checking",
         available_balance, current_balance, currency:"USD" } ]

GET  /accounts/{account_id}/transactions?from=2026-04-01
  -> { items:[ { posted_at, amount, direction,
                 description, type:"ach|deposit|transfer|fee",
                 running_balance } ],
       next_cursor }

# 401 -> POST /auth/refresh { refresh_token }
# Role guard: an employee-scoped token can return fewer
# accounts than an owner token. Do not assume the full
# set is present; reconcile against the entitlement.
      

Where a $6B Oklahoma credit union sits on data rights

TFCU is a federally chartered credit union supervised by the NCUA. The route we run does not depend on a US open-banking mandate, because it is member-authorized access to a member's own accounts. That distinction is doing real work right now: the CFPB's Personal Financial Data Rights rule under Section 1033 was finalized and then enjoined, with the Bureau reconsidering it, so the dated, asset-tiered obligations are not settled law for an institution this size today. We do not build on a timeline that is in flux. Consent is scoped to the data the member names, recorded, time-bound, and revocable; access is logged and data-minimized; an NDA is in place where the client needs one. That posture holds whether or not §1033 lands in its finalized form.

Things this particular build has to get right

Concrete points we account for on this app, handled on our side:

• The two-app split. Business and consumer are separate installs with different entitlements. We bind to the business package and verify that the account set the session sees is the business one, so the integration never silently mirrors a personal profile.
• Owner versus employee scope. The app supports an owner plus employees with customizable permissions. We model the role matrix and scope the connection to the credentialed login, so an employee token does not quietly miss accounts an owner would see — and so the integration acts only within what that user is entitled to do.
• Multifactor step-up. TFCU added new multifactor steps. We design the consented session around the MFA challenge and the refresh window so the connection re-establishes cleanly instead of failing on the next step-up.
• Front-end churn. Hosted digital-banking front ends get re-themed. We keep a check in the maintenance cycle that re-validates the captured flow when the portal changes, so a visual update is a small patch, not a rebuild.

What teams actually wire this into

• A morning cash-position dashboard that reads balances across every business TFCU account before the finance team logs in.
• Nightly transaction sync into QuickBooks or an ERP, so bookkeeping stops depending on someone manually exporting OFX.
• Accounts-payable automation: queue ACH and Bill Pay from an internal system, then read status back for reconciliation.
• Deposit audit — pull mobile-deposit items and match them against open invoices.

Screens from the store listing

Store screenshots, for interface reference. Tap to enlarge.

What was checked, and against what

This mapping rests on the credit union's own business online-and-mobile-banking page (for the data surfaces and the QuickBooks / Quicken Direct Connect path), NCUA call-report records for charter and size, and the current legal status of CFPB Section 1033, reviewed in May 2026. Primary sources opened:

• TFCU Business Online and Mobile Banking — feature list
• CFPB — Personal Financial Data Rights Reconsideration
• Analysis of the order enjoining §1033 enforcement
• NCUA call-report record, charter 24524

Notes compiled by the OpenBanking Studio integration desk, May 2026.

Other credit-union business apps in the same bucket

Same category, useful when a customer banks across more than one institution and wants one normalized feed. Listed for context, not ranked:

• Navy Federal Credit Union — business deposit and transaction data behind a large federal-credit-union member login.
• PenFed Credit Union — member accounts, transfers and payments in a comparable consented-access shape.
• BECU (Boeing Employees' Credit Union) — business balances and activity, plus aggregated external accounts in its app.
• Alliant Credit Union — balances, transaction history, transfers and deposit capture behind an authenticated member session.
• Mountain America Credit Union — business banking with similar account and payment surfaces.
• OnPoint Community Credit Union — Pacific-Northwest credit union with comparable business account data.
• TTCU Federal Credit Union — another Oklahoma credit union exposing member balances and transactions to a logged-in user.
• WSECU (Washington State Employees Credit Union) — member account data in the same authorized-access pattern.
• Truliant Federal Credit Union — business balances, transfers and payment history behind a member login.

Questions an integrator usually asks here

The business app and the regular Tinker FCU app look almost the same — which one do you integrate against?

The business one. TFCU ships a separate install for business members, distinct from the consumer Tinker FCU app, with its own package and its own multi-user login. We target the business package and its authenticated session, and we verify the account set the connection sees matches the business online-banking entitlement rather than a personal profile.

Can the connection act for an employee login as well as the owner, or only the owner?

Both, within whatever each login is entitled to. The app supports the owner plus employees with customizable scope, so we map the role matrix and bind the integration to the permissions of the credentialed user. An employee-scoped session may see fewer accounts or fewer actions than an owner session, and the client is built to respect that rather than assume the full set.

We only need clean statements for our ledger — is a live connection still necessary?

Not necessarily. TFCU's business platform lists QuickBooks and Quicken Direct Connect among its accounting tools, which gives an OFX-format statement path. For ledger import that is often enough on its own, and we will deliver against that surface instead of a live session when statement-grade history is all you need.

Does the integration break the first time TFCU changes its online-banking screens?

That is the risk we design against. We document the auth and transport as a protocol map rather than scraping rendered pages, and we keep a check in the maintenance cycle that re-validates the captured flow whenever the front end shifts, so a re-theme is a small fix instead of a rebuild.

We are an Oklahoma business with a few TFCU accounts — what would the first deliverable actually be for us?

Usually the auth-and-protocol report plus runnable source for the balance and transaction endpoints across your business accounts, with tests, inside a one-to-two-week cycle. Access is arranged with you as part of the work; you give the app name and what you need from its data.

Working with us

Source delivery for the TFCU Business connection starts at $300, billed only after the working code is in your hands — runnable source for the balance, transaction and transfer endpoints, the auth-and-protocol report, automated tests, and interface docs. Prefer not to host it? Call our endpoints instead and pay per call, with nothing upfront. Either way the cycle is one to two weeks. Send the app name and what you need from its data at /contact.html and we set up access and compliance with you from there.