Payroll vs. Banking Data: A Tenant Screener's Guide to Direct-Source Income

In the National Multifamily Housing Council's 2024 Pulse Survey, 93.3% of apartment owners and managers reported experiencing fraud in the prior 12 months. The most common form, seen by 84.3% of respondents: applicants falsifying or fabricating pay stubs, employment references, or other income documentation. Respondents wrote off nearly $4.2 million in bad debt on average over that period — a median of $800,000 — and attributed roughly a quarter of it to non-payment tied to fraudulent applications.
That was before generative AI made a flawless pay stub, something an applicant can produce in under a minute, for free, with no design skill at all.
The real answer isn't only better forgery detection. It's minimizing the need to review documents that are prone to forgery. That's what direct-source connections do, and it's why the screening industry has moved toward them. But "direct-source" covers two very different connection types — payroll and banking — that answer different questions and can support different types of applicants.
.png)
Why direct-source data changes the fraud equation
Every traditional income check has the same structural weakness: it runs on the document the applicant provides you. A pay stub, a bank statement PDF, an offer letter, an employer's phone number. Each one passes through the applicant's hands before it reaches yours, and anything that passes through the applicant's hands can be altered.
A direct-source connection removes that step. The applicant logs into their own payroll or bank account and directs their records to be shared with you. The data moves from the system of record to your screening workflow without an intermediate file anyone can edit.
That changes three things at once:
- There's no document to forge. Not a harder-to-forge document — no document. Tampering isn't detected; it's structurally unavailable.
- The provenance is unambiguous. You know the record came from the applicant's payroll account or their bank, because that's the only place it could have come from. You aren't evaluating whether a PDF looks legitimate.
This is why the source of the data, not the processing on top of it, is the thing to evaluate. First-party records shared straight from the source are high-trust because of where they come from — not because someone downstream scored or cleaned them. Inhabit, which uses both connection types, describes the effect this way:
"There's little opportunity for fraud to enter the workflow when we're leveraging payroll and banking data applicants share directly from the source using Argyle. The only opening is when someone submits a document, and Argyle's document processing helps us identify fraud or manipulation there, too."
— Lisa Chall, Vice President of Screening and Compliance, Inhabit's Residential Division
Inhabit now completes up to 90% of income verifications entirely through digitally sourced data, keeping applicant-uploaded documents out of most of the workflow. Read the full case study.
.png)
How a payroll connection works — and what it returns
An applicant searches for their employer or payroll provider, logs in with their own credentials, and directs those records to be shared with you.
What comes back is the payroll record itself, structured:
- Gross and net pay for each pay period, with year-to-date totals
- Employer name, employment status, and hire date
- Pay frequency and pay type — hourly, salaried, contract, gig
- Base pay and rate, plus overtime, bonus, and commission where applicable
- Deductions and garnishments, itemized
- Historical pay statements and tax documents, shared straight from the source
The distinguishing feature is that none of it is inferred. Gross pay is read from the payroll system, not modeled backward from a deposit. Employment status is a current field, not a guess based on whether money showed up last Friday.
Where payroll connections are strongest: W-2 employees, salaried and hourly workers, gig platform workers, anyone whose pay runs through a payroll system. That's the large majority of rental applicants — Argyle's consumer-permissioned verification platform covers over 91% of the U.S. workforce.
Where they fall short: applicants paid in cash, some independent contractors invoicing directly, workers at very small employers using no payroll platform, and anyone with meaningful non-employment income — benefits, retirement distributions, alimony, rental income, investment income.
.png)
How a bank connection works — and what it returns
An applicant connects a bank account, and the deposit history becomes visible. A model then classifies each recurring inflow: is this a paycheck, a peer-to-peer (P2P) transfer, a tax refund, a benefits payment, a one-time gift?
What comes back:
- Deposit history and cadence, useful for judging income stability over time
- Total inflows across every source — including cash deposits and 1099 income that never touches a payroll system
- Income stream classification, with recurring streams separated from one-off transfers
- Account balances, which matter when you're assessing reserves
That first bullet is the real strength, and it's a genuine one: a bank account sees all the money, wherever it comes from. Payroll sees one employment relationship at a time.
The trade-off is that bank data is derived. A deposit is an observed event; income is an interpretation of it. Three specific gaps matter for screening:
- Gross income is modeled, not read. Deposits are net. Getting to gross means estimating tax withholding without knowing filing status, state, or pre-tax deductions. Mastercard recently refined the net-to-gross calculation behind Argyle's Banking VOI with recalibrated federal brackets and state-specific rates — meaningful improvement, and still an estimate. Most rent-to-income ratios are written against gross.
- The employer is a text string. A deposit descriptor may name a payroll processor rather than the employer, or arrive truncated. It isn't an employer of record.
- Employment status is inferred. A bank account tells you money arrived on a date. The next deposit is predicted based on the historical cadence of payments, marking the income stream as active or inactive based on if the deposit is delivered by a certain date.
Where bank connections are strongest: applicants with income outside a payroll system, multiple or irregular income sources, self-employment, or non-employment income. This population is larger than it looks: at Inhabit, 40% of applicants have income from more than one source, including second jobs, gig work, and other income such as child support.
Where they fall short: any decision that turns on a precise gross figure, a named employer, or current employment status — a rent-to-income ratio calculated to the dollar, an applicant who started a new job last month, or a file where you need to know the employment relationship exists today rather than last pay cycle.
Why the sequence matters
Set side by side, these aren't competing options — they're complementary ones. Payroll gives you precision about employment income. Banking gives you completeness about all income. A screening workflow built on only one of them is leaving applicants, and accuracy, on the table.
So both connection types belong. The order is what determines how many applicants clear without friction.
.png)
Start with payroll. It's the only layer that returns gross pay, employer, and employment status without inference. For most applicants it resolves the question completely, in seconds, with nothing left to interpret. Argyle sees an average of 55% net conversion across the full applicant journey.
Fall back to banking. For the applicants payroll doesn't reach — cash-paid workers, independent contractors, anyone with significant non-employment income — banking is the solution. It captures income payroll would have missed.
Keep documents as the fallback. For the remainder, Argyle's document upload solution processes the documents applicants provide and returns structured income data.
Screeners see the effect in completion rates. After adding Argyle, Snappt reported up to a 30% increase in application completion— alongside Inhabit achieving 90% completion rate of income verifications with digitally sourced data (payroll and banking). All three case studies are on our Customer page.
Speed is the other half of it. Before moving to direct-source data, Inhabit found that verification-related issues added an average of 24 hours to the process, and three to four days in more serious cases — delays that land on the applicant as hard as they land on the operator.
What to ask any provider
- Customer proof. Which tenant screeners use Argyle today, at what scale, and what performance metrics (conversion, etc.) are they seeing?
- Data completeness. How often do the fields you actually need come back populated? Argyle returns required income and employment attributes at up to 95% data completeness.
- Applicant experience. Can an applicant connect on a phone, recover a forgotten login, and complete the flow with a screen reader?
- Troubleshooting documentation. Is error documentation, handling, and troubleshooting clearly outlined for both the customer and applicant?
The bottom line
Bank data tells you what landed in an account. Payroll data tells you what an employer paid. Neither is a substitute for the other, and the screeners getting the most out of direct-source data aren't choosing between them — they're leveraging both to optimize number of verifications through direct-source data and minimize document collection
What both share is the thing that matters most against fraud: the applicant is sharing the data, not handing over a file. There's nothing in the middle to alter.
If you'd like to see how direct-source payroll and banking would perform against your current workflow, reach out to our team.


