Reaching the HRA balances and claim history behind a Via Benefits Accounts login

Available Balance in Via Benefits Accounts is split by plan year, and unused funds can roll forward into the next one with a deadline for incurring expenses — that is the first thing any integration here has to model correctly, because a single balance number is wrong by design. The app is the participant-facing front end for Health Reimbursement Arrangements (and HSA/FSA accounts) administered by Via Benefits, the retiree and Medicare exchange business now part of WTW; account services run under the Acclaris name, which is also the package identifier (com.acclaris.mobile.acclaim per its Google Play listing). What a third party usually wants from it is plain: the balance per plan year, the claim and payment ledger, and the status of reimbursement requests in flight.

Bottom line: there is real, structured per-participant data behind the login, and it changes on a monthly cadence as premiums get reimbursed. The route we would actually take is consented protocol analysis of the authenticated traffic the app and portal already produce, with the work scoped per sponsor plan. The rest of this brief is specifics.

Reimbursement data inside the account

Each row below is a surface a participant sees in the app or at viabenefitsaccounts.com, named the way Via Benefits names it in its help material where possible.

Routes that genuinely apply here

1 — Consented protocol analysis of the authenticated app and portal

The app and the viabenefitsaccounts.com portal both run against the same back end after sign-in. We document that traffic — the sign-in exchange, the token it returns, and the calls that load Available Balance, Activity and Payments — and rebuild it as a clean interface. Reachable: everything in the table above for the consenting participant. Effort is moderate; durability is good between front-end revisions and handled by the maintenance step. Access is arranged with you during onboarding: either a participant authorizing access to their own account, or the sponsor/administrator relationship under a Business Associate Agreement.

2 — Single-account user-consented access

For one participant who consents to their own data, a narrower build covers balance, activity and claim status without touching anyone else's plan. This is the fastest path to a working read and a good first milestone before a multi-sponsor rollout.

3 — Sponsor / administrator integration under a BAA

For a plan sponsor or third-party administrator that needs payment and scheduled-payment data across a population, the same interface runs at book scale, scoped per sponsor plan, with the BAA and access set up as part of the engagement. Where a sponsor turns on document or statement downloads, those feed in as a supplementary source.

We would recommend route 1 as the backbone and stand up route 2 first as a proving milestone, then widen to route 3 once the per-sponsor rule mapping is in place. Picking that order keeps a working read in your hands within the first cycle.

A look at the authenticated traffic

Sign-in goes through an Azure-style identity flow (the account-management host sits on an Azure B2C sign-in page), which returns a short-lived bearer token used for the account calls. The shape below is illustrative and confirmed during the build — it is not copied from any Via Benefits documentation.

# Illustrative. Exact hosts and claim names are confirmed during the build.

POST  https://<auth-host>/<b2c-policy>/oauth2/v2.0/token   # sign-in
      grant_type=authorization_code  scope=openid <accounts-api>
  -> { "access_token":"<jwt>", "expires_in":3600, "refresh_token":"<...>" }

GET   https://<accounts-api>/participants/me/accounts
      Authorization: Bearer <jwt>
  -> [ { "accountId":"...", "planYear":2026, "type":"HRA",
         "availableBalance":1840.00, "currency":"USD",
         "rollForward":true, "incurDeadline":"2027-03-31" } ]

GET   https://<accounts-api>/participants/me/accounts/{id}/activity?from=2025-01-01
  -> [ { "date":"2026-02-11", "kind":"Reimbursement",
         "status":"Paid", "amount":215.40,
         "method":"DirectDeposit", "claimId":"..." } ]

# Direct-deposit setup hands off to an instant bank-verification redirect.
# We treat that as an external consent step, never a scraped credential.
      

Note the per-plan-year keying and the rollForward / incurDeadline fields. A balance read that ignores them silently loses carried-forward funds.

What ships at the end of the engagement

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

• An OpenAPI/Swagger specification covering the account, activity, payments and claim-submission calls as they actually behave for Via Benefits Accounts.
• A protocol and auth-flow report: the Azure-style sign-in exchange, token lifetime and refresh, and the direct-deposit verification handoff.
• Runnable source for the key endpoints in Python and Node.js — balance by plan year, Activity pull, Payments and Scheduled Payments, claim status.
• Automated tests, including the roll-forward and incur-deadline edge cases and a multi-sponsor eligibility case.
• Interface documentation plus HIPAA-aligned data-retention and minimization guidance for whatever you store downstream.

Where teams actually use this

• A retiree-services firm consolidating HRA balances across a book of Medicare clients into one advisory view.
• A reimbursement-automation tool that drafts claims, attaches receipts, and reconciles when a payment posts as "Paid".
• A financial-wellness app classifying medical out-of-pocket spend from Activity against the §213(d) eligible set.
• A sponsor or administrator pulling Payments and Scheduled Payments for plan-utilization reporting under a BAA.

HIPAA, ERISA and consented access

An HRA is generally treated as a self-funded group health plan that handles protected health information — medical expenses and reimbursement claims are PHI. That sets the rules. A third party that touches that data operates as a business associate under a Business Associate Agreement with the plan or its administrator; HIPAA Privacy and Security obligations apply directly to that associate, ERISA governs the plan's claims and appeals, and eligibility tracks IRS §213(d) plus the sponsor's plan document. There is no US open-banking scheme in play here — the direct-deposit bank link is an external instant-verification handoff we read the result of, not a credential we hold. Consent scope is limited to the data domains in use, reads are minimized and logged, access is revocable, and NDA and BAA paperwork is arranged with you during onboarding rather than asked of you up front. That is how the studio operates, not a gate at the door.

Engineering realities we plan around

Two things about this app drive the design, and we handle both:

• Per-sponsor plan rules. Which expenses are reimbursable and how an account is funded differ by employer because each sponsor sets its own plan document on top of §213(d). We map the per-sponsor rule set and key every participant to their sponsor plan, so two participants on different plans are processed correctly inside one integration.
• Plan-year roll-forward. Available Balance is keyed by plan year, carries funds forward, and applies a deadline for incurring expenses. We model balances as per-year records with the carried-forward amount and deadline preserved, instead of flattening them into one number that goes stale at year boundaries.
• Token lifetime. The sign-in token is short-lived. We design the sync around its refresh window so it renews ahead of expiry rather than dropping mid-cycle, and we keep the direct-deposit instant-verification redirect as an external consent step.
• Front-end change. The app and portal screens get revised. We keep a re-validation step in the maintenance window so a layout or endpoint change is caught and patched quickly instead of failing silently.

How the work is bought

Two models, stated plainly. Source-code delivery starts at $300: you get the runnable source, the spec, tests and interface docs, and you pay after delivery once the integration is working to your satisfaction. Or use the hosted API and pay per call, with no upfront fee and nothing to run yourself. A normal build lands in one to two weeks. Tell us the app and what you need from its data — access and compliance paperwork are arranged with you as part of getting started.

Screens from the app

What was checked, and when

Worked from the Play and App Store listings and the public Via Benefits help library: the balance and activity article for the Available Balance, Activity, Payments and Scheduled Payments terms; the direct-deposit article for the instant bank-verification redirect; the automatic premium reimbursement article for the recurring schedule; and an employer-group-health-plan HIPAA primer for the PHI and Business Associate Agreement framing. Sources opened:

• Via Benefits — Viewing Your Reimbursement Account Balance
• Via Benefits — Set Up Direct Deposit (instant bank verification)
• Via Benefits — How Automatic Premium Reimbursement Works
• HIPAA Privacy & Security primer for employer-sponsored group health plans

Notes from the OpenBanking Studio integration desk, reviewed 2026-05-16.

Other reimbursement-account apps in the same space

Same category, useful when one normalized interface needs to sit across several account administrators:

• HealthEquity — HSA, FSA and HRA balances, claims and a debit-card payment rail.
• Optum Financial — HSA/FSA/HRA accounts with receipt capture and bill pay.
• Inspira Financial — HSA and reimbursement accounts managed online and in-app.
• WEX benefits — the payments backbone behind many branded FSA/HSA programs.
• PayFlex Mobile — real-time FSA, HSA and HRA balances and claims.
• MetLife HS&SA — HSA, HRA and FSA balances and account detail.
• Lively — HSA, FSA, HRA, LSA and COBRA / direct-bill accounts.
• Ameriflex — FSA, HSA, HRA and LSA administration.
• Benepass — lifestyle, HRA, FSA and commuter benefit accounts.
• Voya Health Account Solutions — HSA, FSA, HRA and COBRA administration.

Questions integrators ask about Via Benefits Accounts

Does the integration handle plan-year roll-forward and the incur-by deadline, or just one balance number?

It models the account per plan year. Via Benefits help material describes Available Balance split by year with funds that can roll forward and a deadline for incurring expenses, so we carry the plan year, the carried-forward amount and the deadline as separate fields rather than collapsing them into a single figure.

Sign-in to Via Benefits Accounts runs through an Azure-style identity flow. How do you keep a sync authenticated?

The protocol report documents the sign-in exchange and the short-lived token it issues. We build the sync around the refresh window so it renews before expiry instead of failing mid-cycle, and the direct-deposit instant bank-verification redirect is kept as an external consent step, not a stored credential.

We administer HRAs for several sponsors with different eligible-expense rules. Can one integration cover all of them?

Yes. Eligibility follows IRS section 213(d) plus each sponsor's plan document, so reimbursable rules differ by employer. We map the per-sponsor rule set and key every participant to their sponsor plan so two people on different plans are handled correctly under one integration.

There is protected health information in reimbursement claims. How is that handled?

HRAs are treated as self-funded group health plans that handle PHI, so a third party touching that data operates under a Business Associate Agreement with the plan or its administrator. We scope access to the data domains in use, minimize and log what is read, and arrange the BAA and NDA as part of onboarding.