How to Build Creator Income Verification for Lending

Creator lending has an obvious data problem and a less obvious modelling problem. The data problem is that creators have no payslips, which is why this vertical exists. The modelling problem is that once you solve the first one, the numbers you get are far spikier than anything a traditional income model expects.

A platform API read gives you real revenue figures, which is genuinely better than a screenshot or a self-declared total. It does not give you an underwritable income figure on its own, and the gap between those 2 things is where this guide lives.

What follows assumes you already know which platforms expose revenue and how the figures behave, which is covered in creator income data via API.

Why does the average mislead?

Because creator income is not distributed like salary. It is mostly flat with occasional large spikes, and a mean treats a spike as though it were normal.

Take a creator earning around $3,000 a month, steadily, for a year. Now give them 1 video that takes off and earns $28,000 in a single month.

The viral month moves the mean by 70% and the median by 1.7%. A lender underwriting on the mean assumes $5,117 a month against a reality of about $3,025, which overstates capacity by 69%.

That is not a rounding error, it is the difference between a loan that performs and one that defaults. Use the median, and look at the minimum as well, because a creator's worst month is usually a better guide to repayment capacity than their average one.

A practical rule: underwrite on the trailing 12 month median, size the payment against the trailing 12 month minimum, and treat anything above the 90th percentile as upside rather than income.

Which months can you actually use?

Settled ones. Platform revenue figures are estimates that get adjusted twice, roughly a week after generation and again in the middle of the following month.

So a decision made on 3 October should use data through August, not September. Build that into the model rather than leaving it to whoever runs the report, because the temptation to include the most recent month is strong and it is always the least reliable one.

Which platforms expose revenue at all decides what you can verify. The field list is public. See the coverage list

How do you score verification confidence?

By scoring the inputs separately rather than producing 1 opaque number. Each component answers a different question a credit committee will ask.

# Confidence is 4 independent checks, not a blend.

def verification_confidence(applicant):
    return {
        # 1. How much of their claimed income can you see?
        "coverage": verified_median / max(declared_median, 1),

        # 2. How much settled history is there?
        "history_months": count_settled_months(applicant),

        # 3. How stable is it? Lower is steadier.
        "volatility": stdev(settled) / median(settled),

        # 4. Is the connection still live?
        "connection_state": token_state(applicant),   # LIVE | STALE | DEAD
    }

# Decision rules, kept explicit so they can be defended:
#   history_months <  6            -> insufficient history, decline or refer
#   coverage       <  0.3          -> most income unverified. Refer.
#   volatility     >  1.0          -> spikier than median. Size to minimum.
#   connection_state != "LIVE"     -> cannot monitor. Do not disburse.
#
# Never multiply these into one score. A committee asking why an
# application was declined needs the component, not the product.

The coverage component is the one most teams omit, and it is the most informative. A creator declaring $12,000 a month with $4,100 verified has coverage of 0.34, which tells you most of their stated income is invisible to you. That is not a reason to decline, and it is a reason to price differently from an applicant at 0.9.

Keeping the components separate also matters for adverse action. A single blended score cannot be explained to an applicant or a regulator, which is the same objection we raised against composite risk scores in screening.

What does the connection actually prove?

That whoever completed the OAuth flow had access to the account. Not that they own it, and not that they receive the money.

This matters more in creator lending than elsewhere because managed accounts are normal. An agency, a manager or a family member may hold credentials, and a connection they complete looks identical to one the creator completes.

3 mitigations, in rough order of strength.

1. Match the payout identity. Where the platform exposes an account or channel identifier, check it against the applicant's own records rather than relying on the connection alone.
2. Resolve the applicant across platforms. A creator who connects 4 accounts that all resolve to 1 consistent identity is a stronger signal than 1 isolated connection, which is what identity resolution is for.
3. Ask the creator to complete the connection during a session you control, rather than accepting a connection made earlier by an unknown party.

None of these are conclusive and together they are considerably better than treating an OAuth grant as proof of ownership, which is what most early products do.

How often should you re-verify?

More often than the loan term, because the connection will not survive it untended.

Access tokens expire on platform schedules, creators disconnect apps without telling anyone, and Google revokes YouTube-scoped refresh tokens when a user changes their account password. Over a 24 month loan, a connection left alone will almost certainly die. The mechanics are in the token lifecycle guide and the operational side in refresh at scale.

2 things to build. A monthly re-read of settled revenue so you have an income trend rather than a snapshot. And a reconnect prompt that fires on a dead connection, with the consequence stated plainly to the borrower, because a silent dead connection means you are monitoring nothing while believing you are.

Worth deciding up front what a lost connection means contractually. If continued verification is a condition, say so at origination rather than discovering the question at month 14.

What about consent and retention?

Treat the connection as consent for a stated purpose with a stated duration, and record it. A borrower agreeing to income verification at origination has not agreed to indefinite monitoring of everything the token can reach.

Keep the scopes to revenue and whatever identity fields you genuinely need. A lending product requesting content and messaging scopes is collecting data it cannot justify, and it lowers connect rates for nothing, which is covered in account connection UX. Retention and deletion handling is in consent and data retention.

Summary

Verified income is not the same as underwritable income. Use trailing medians rather than means, because a single viral month moves a mean by 70%, and size payments against the worst month rather than the average one.

Underwrite on settled months only, score coverage, history, volatility and connection state as separate components you can defend, and remember that an OAuth grant proves access rather than ownership. Then re-verify monthly, because a connection left alone for a 24 month term will not last it.

Want verified platform revenue with the connection and token handling already built? Get a demo