First-party vs third-party fraud: why the split matters

Third-party fraud and first-party fraud produce the same loss amount from opposite causes. In third-party fraud someone transacts as a customer they are not: a stolen card, an account takeover, an impersonated applicant. In first-party fraud the real account holder causes the loss deliberately, by misstating an application or borrowing with no intent to repay. The distinction changes which model you build and how you treat the loss.

Once you accept that, a lot of downstream confusion resolves. Many fraud programs feel like they are running to stand still because they train one model and set one policy across two populations that share almost nothing except the ledger entry.

The taxonomy is an operational decision, not a naming exercise

People treat fraud taxonomy as vocabulary. It is closer to a routing table. The label you attach to a loss decides which team owns it, which model scores it, which recovery path it enters, and which line it hits in the P&L.

The cleanest cut is by who is transacting relative to who is on record:

• Third-party: the transacting party is not the person of record, and the person of record is a victim. Stolen credentials, card-not-present abuse, account takeover, synthetic identities that borrow a real person’s data.
• First-party: the transacting party is the person of record, and there is no separate victim. Application misrepresentation, bust-out, and never-pay accounts where the intent to default existed at booking.

There is a genuinely awkward middle. A synthetic identity built partly from a real person’s SSN sits between the two, and refund abuse by a real customer is first-party behaviour that many teams file under disputes rather than fraud at all. You do not resolve those by arguing about definitions. You resolve them by writing down the decision rule your organisation will apply consistently, then holding the label stable so that six months of history means the same thing end to end. A taxonomy that drifts is worse than a coarse one, because your eval sets inherit the drift and you can no longer tell whether the model got worse or the labels moved.

Why one model cannot serve both

The two populations separate in time, and time is most of what a fraud model has to work with.

Third-party losses concentrate around events: the moment of application, the first card-not-present transaction, a password reset followed by a new payee. The signal is a mismatch between the claimed identity and the behaviour, and it is often detectable in the first hours. Velocity, device and IP reuse, entity resolution across applications, a shipping address that has appeared on four other accounts this week.

First-party losses do not announce themselves at onboarding, because at onboarding nothing is technically false about the identity. The person is who they say they are. What is false is the stated income, the stated intent, or the affordability the underwriting assumed. That signal surfaces later: at first-payment default, in a bust-out pattern where utilisation climbs toward the limit right before the account goes dark, in a cluster of accounts opened from the same funnel that all default in the same vintage.

So the features differ, the labels arrive on different clocks, and the maturation window differs. If you pool them into one target you get a model that is mediocre at both. Concretely:

• Label timing. A third-party label can be confirmed within days. A first-party bust-out is not confirmable until the account has aged, sometimes past quarter-end. Train on a snapshot and your first-party positives are still unlabelled, so the model learns they are negatives. This is lookahead running in reverse. Nothing from the future is leaking into the features; the future simply has not arrived, so an unlabelled bust-out gets scored as a good account.
• Point-in-time correctness. First-party features lean on repayment and utilisation trajectories. If your feature store serves the current balance instead of the balance as-of the scoring date, you have trained on the outcome. The account defaulted, so of course utilisation was high.
• Cost asymmetry. A false positive on third-party is a declined transaction and an annoyed genuine customer. A false positive on first-party is a declined applicant and a fair-lending question, because the adverse decision has to be explainable under ECOA. Your false-positive budget is not one budget. It is two, denominated in different currencies.

Build two models, or at least two heads on a shared representation, each with its own labels and thresholds. Then report them separately, so the fraud number and the credit number stop borrowing from each other.

The classification quietly distorts everything downstream

Here is the part that costs real money and is nearly invisible on a dashboard. First-party fraud looks exactly like credit default, so it gets booked as credit loss. The account was extended in good faith, the customer stopped paying, the loss flows to the credit line and into expected credit loss provisioning. Nobody flags it, because the arithmetic reconciles.

The consequences compound:

• Your fraud rate is understated and your credit loss is overstated, so capital and provisions are being set against the wrong cause.
• Underwriting never learns which application patterns predicted a never-pay, because those accounts were labelled as ordinary defaults and fed back into the credit model, not the fraud model.
• The recovery team chases first-party fraud through a collections path built for customers who fell behind, not for people who never intended to pay, which wastes the effort and leaves the actual pattern undetected.

Fixing this is unglamorous. It is a reconciliation and lineage problem before it is a modelling problem. You need charge-off reason codes that can carry a first-party fraud designation, an audit trail that records why an account was reclassified, and a periodic sweep that re-examines credit charge-offs for bust-out signatures. The reclassification has to be defensible, because you are moving a loss between regulatory buckets and someone will ask you to justify it.

The payoff is that your fraud numbers start describing fraud, your credit numbers start describing credit, and every model downstream is finally training on labels that mean what they say. Straight-through processing on the clean cases becomes safe because the label feeding the decision means the same thing at the point it is applied as it did when the model was trained. None of it works until the split is real in the data, not just in the slide that describes it.