Reaching earned-pay balances and transfers in PNC EarnedIt

The number a PNC EarnedIt user opens the app to check, their available balance, is not their paycheck. It is an advance-rate slice of wages already accrued this pay period, recomputed as worked hours post from the employer's time-management system. That single moving figure, plus the transfers it funds and the payout accounts those transfers land in, is the data most teams want out of this app, and it changes through the day rather than once at payday. Getting it right is mostly a reconciliation problem: keep a read in step with how the balance accrues, and make the early transfers plus the payday remainder add back up to net pay.

PNC EarnedIt is the PNC-branded build of DailyPay's on-demand pay platform, an opt-in employer benefit in the United States, per its PNC and Google Play listings (package com.DailyPay.PNC). Below is what it holds, the consented way in, and what we hand over.

What the app actually holds

Every row below maps to something a worker can see in the app. Granularity reflects what the surface exposes, not what we wish it did.

Getting to the data, and which way we'd take

Two or three routes fit this app. Each reaches roughly the same surfaces; they differ in how durable they are and how much the worker stays in the loop.

Worker-consented access

The app authenticates over OAuth 2.0. The authorization-code flow has the worker grant consent to read their available earnings and, optionally, to initiate transfers on their behalf. Reachable: balance, transfer history and state, linked accounts. Durable: a refresh token keeps the session alive across expiry, and the worker can revoke. We set up the consent capture, token storage and refresh-before-expiry handling as part of the build.

Authorized interface analysis

Under your authorization, we observe and reproduce the app's own authenticated JSON interface, the small set of resources it reads for balances, transfers and accounts, including the version header it sends. Reachable: the same surfaces, plus the pagination and versioning nuances a typed client needs to be stable. Effort is moderate; durability is good as long as we pin the version we built against and re-check on a cadence.

In-app view as a manual fallback

For a one-off or very low volume, the balance and transfer history a worker can already see in the app is enough to export by hand. Low effort, low durability, no automation.

For anything past a one-off, build on the worker-consented flow. It survives token expiry through refresh and keeps the worker in control of what is shared. Interface analysis fills the corners the consent scope leaves out, and the in-app view stays a manual backstop for small jobs.

What lands in your repo

The headline is code that runs against this app's real surfaces, with the spec and reports underneath it.

• Runnable client source in Python and Node.js for the earnings-balance read, transfer initiation, and account listing, with typed models and retry/backoff on the wire.
• A reconciliation runner that matches available-balance snapshots against transfer and settlement events and flags drift, so an early transfer plus the payday remainder ties back to net pay.
• An automated test suite running against recorded fixtures: balance reads, transfer-state transitions, and fee lines.
• A balance-change handler that turns the app's change notifications into normalized internal events for your queue.
• A sync design setting the read cadence to the balance's posting rhythm and cursoring transfers so nothing is missed or double-counted.
• Underneath that: an OpenAPI description of the mapped surface, an auth-flow report covering the OAuth token and refresh chain, interface documentation, and data-retention and consent guidance.

On the wire

Illustrative, with shapes confirmed against the live app during the build. The available-earnings read is the spine; balances come back in minor units.

GET /rest/accounts?account_type=EARNINGS_BALANCE
Authorization: Bearer <worker-consented token>
DailyPay-API-Version: 3

200 OK
{
  "data": [{
    "id": "acct_…",
    "type": "accounts",
    "attributes": {
      "name": "DailyPay Available Earnings",
      "account_type": "EARNINGS_BALANCE",
      "subtype": "ODP",
      "balances": { "available": 12000, "current": null, "currency": "USD" }
    }
  }]
}
# balances.available is in cents -> 12000 = $120.00
# 401 -> refresh the worker token; 429 -> back off and retry with jitter

We normalize that into one internal record per worker, so the rest of your stack never touches the raw shape:

// emitted per worker, per read
{
  worker_id:      "wk_…",            // sponsor + person id
  sponsor:        "employer-plan-id",
  available_cents: 12000,            // EARNINGS_BALANCE -> balances.available
  currency:       "USD",
  as_of:          "2026-06-08T14:05:00Z",
  open_transfers: [
    { amount_cents: 5000, speed: "instant", status: "pending", fee_cents: 299 }
  ]
}

Keeping the balance honest

The available figure is a derived number, not a stored one. It is the advance-rate share of what has accrued, before taxes and deductions, which is why it is always below total dollars earned. Three things move it: hours posting from the employer time system, transfers the worker makes, and the payday settlement that zeroes the period. We design the read so those stay aligned: cadence matched to how often hours post, instant and next-business-day transfers tracked through their own state transitions, and a close-of-period check that confirms transfers plus the remaining pay equal net. When a snapshot and the transfer ledger disagree, the runner writes a drift record rather than letting a stale number ride.

Consent and the earned-wage rulebook

The dependable basis is the worker's own authorization to reach their pay data. PNC EarnedIt is opt-in and enrollment-required, so access rides a consent the worker grants and can revoke; we keep the consent record and an access log with the build, request the narrowest scope the job needs, and minimize what we store (last-four references, not card numbers).

The earned-wage classification itself is in flux, and it matters for what you build on top. The CFPB rescinded its July 2024 proposal that would have treated many earned-wage products as credit under the Truth in Lending Act, and in December 2025 took the position that employer-partnered earned-wage access is not credit under TILA, per the Federal Register notice. Treat the federal data-rights rule (the CFPB's Personal Financial Data Rights rule) as forward-looking rather than operative: it is not in force, so we do not lean on it. Worker consent is what the integration relies on today.

Things we account for in the build

These are the parts of PNC EarnedIt that bite if you ignore them, and how we handle each one.

• Available balance is not total earned. It is an advance-rate slice of accrued, pre-withholding pay. We model the advance-rate logic so our figure matches what the worker sees, and reconcile against payday settlement so early transfers plus the remainder equal net pay.
• Plans differ by employer. Advance rate, the instant-versus-next-day fee schedule, and eligibility are set per sponsor. We map the plan rules per employer and key our models to the sponsor, so two workers on different plans each get their own rules.
• Transfers settle on different clocks. Within-minutes payouts clear 24/7 including weekends and holidays; next-business-day ones do not. We model the transfer-state lifecycle so a pending next-day payout is not double-counted against the balance.

What the app looks like

Store screenshots, useful for mapping which value sits on which screen. Tap to enlarge.

Other earned-wage apps in the same orbit

If you are unifying on-demand pay across providers, these sit in the same category and hold comparable per-worker data. Plain ecosystem context, not a ranking.

• DailyPay — the platform PNC EarnedIt is built on; its own consumer app holds the same available-earnings and transfer records.
• Payactiv — earned-wage access with direct-to-bank transfers, bill pay and a prepaid card option, integrated with payroll systems.
• Tapcheck — employer-offered early wage access through a mobile app, with balance and transfer data per worker.
• ZayZoon — earned-wage access plus financial-wellness tooling, aimed at small and mid-sized employers.
• EarnIn — pay access, early deposit and money tools tied to a worker's pay timing.
• Branch — workplace wallet and faster pay, holding payout-account and transfer data.
• Clair — workplace-connected banking with free earned-wage advances and a linked spending account.
• Rain — employer-integrated earned-wage access reading accrued pay from time and payroll systems.

Questions integrators ask us

How fresh is the available-balance figure, and how often should we re-read it?

The balance builds through the pay period as worked hours post from the employer's time-management feed, so it moves several times a day rather than once. We set the read cadence to match that posting rhythm and reconcile at period close; instant and next-business-day transfers also adjust it on different timelines, which the sync accounts for.

Can the integration both read a worker's balance and start transfers, or only read it?

Both are reachable. The worker-consented authorization flow can be scoped to read available earnings only, or to also initiate a transfer to a linked bank account, debit, prepaid or pay card. We request only the scope your use case needs and keep the consent record with the build.

How do you handle workers spread across different employers and plan rules?

PNC EarnedIt is an employer-sponsored benefit, so advance rate, fee schedule and eligibility vary by sponsor. We map those plan rules per employer and key our models to the sponsor, so two workers on different plans are each handled with their own rules instead of one averaged guess.

Is what we build treated as lending, given the earned-wage angle?

That classification is unsettled. The CFPB rescinded its July 2024 proposal that would have treated many earned-wage products as credit, and in December 2025 took the position that employer-partnered earned-wage access is not credit under the Truth in Lending Act. Our access rides the worker's own authorization to their pay data either way, and we keep the consent and logging records that posture needs.

How this was put together

Checked in June 2026 against the app's own listings and the current regulatory record: the PNC EarnedIt program page, DailyPay's PNC EarnedIt program terms, the Google Play listing for com.DailyPay.PNC, and the December 2025 Federal Register notice on earned-wage access and Regulation Z. Surface shapes are stated as illustrative and reconfirmed during a build.

• PNC EarnedIt program overview (pnc.com)
• PNC EarnedIt program terms (dailypay.com)
• PNC EarnedIt on Google Play
• Truth in Lending (Reg Z); non-application to earned-wage access, Federal Register, Dec 2025

OpenFinance Lab · reconciliation and interface engineering notes — 2026-06-08.

Working together on PNC EarnedIt

A mapped earnings client for PNC EarnedIt, with its reconciliation runner, tests and documentation, starts at $300, and you pay after delivery once it reads real balances correctly and you are satisfied. Prefer not to run anything yourself? Call our hosted endpoints for the same surfaces and pay only per call, with nothing upfront. A typical build runs one to two weeks. Tell us the app name and what you need from its data at /contact.html and we will scope it.