Labels and delayed outcomes

A baker wants to know whether customers liked a new rye loaf. The evidence comes in pieces. A customer says ‘lovely’ at the counter, which is quick and polite and not worth much. Another comes back for a second loaf the next Saturday, which is strong evidence that arrives a week late. A third never returns, and the baker cannot tell whether they disliked the bread or moved house.

The baker is dealing with three things an ML system also deals with. The counter comment is a proxy, a cheap stand-in for the thing you want to know. The repeat visit is a delayed outcome, trustworthy but slow. The customer who never returned is an unresolved case, and writing them down as ‘disliked it’ would poison the baker’s judgement without anyone noticing.

The analogy breaks on scale, since the baker has forty customers and can ask them, while a payment system scores millions of payments and has no one to ask, so proxies, waiting windows and a rule for unresolved cases replace the conversation. The rest of this topic uses payment fraud as the running example, where the delayed outcome is a chargeback, meaning the cardholder disputes the payment with their bank and the money is pulled back.

For payment fraud, a confirmed chargeback is a positive label. A payment made last week with no chargeback yet is not a trustworthy negative, because disputes take weeks to arrive, and a payment made yesterday tells you almost nothing either way. The label definition therefore needs three states, positive, negative and unresolved, and the unresolved state has to be kept rather than rounded down to zero.

The same payment can be judged by several witnesses. The cardholder’s dispute, a fraud analyst’s review, an automated rule that fired, and a user report of a stolen card are all evidence about the same event, and they differ in speed and reliability. Recording which witness supplied each label and when it arrived is what lets you decide later which of them are good enough to train on, which are good enough only for evaluation, and which should be ignored.

A waiting window is the time you agree to wait before calling a payment negative, and for card disputes a 60-day window is a reasonable working assumption for this topic. Under that rule a payment made yesterday stays unresolved, a payment made 35 days ago with a dispute is positive, and a payment made 70 days ago with no dispute becomes negative. A small number of late disputes and unreported frauds will still be hiding among those negatives, in the way the baker’s silent customers hide among the satisfied ones. Measuring how many disputes arrive after day 60 tells you how much to trust the negatives.

A cohort is the set of payments made in the same period, and the cohort is mature once its waiting window has passed. Training on mature cohorts means every label has had its 60 days, and it also means the newest training data is two months old, so a fraud pattern that started last week is invisible to the model. That gap is the price of clean labels, and a design that cannot afford it has to find faster evidence.

Faster evidence exists, and each faster source carries a bias of its own. Analyst reviews arrive within a day, but analysts only review the payments a model or a rule flagged, so their labels describe suspicious payments rather than all payments. A common design trains the main model on mature chargebacks and uses the fast review labels for monitoring and for a smaller, more recent model. The two sources should first be checked against each other on the payments they both cover.

The payments that receive labels are not a random sample of all payments. A fraud system that blocks a payment prevents the chargeback it would have caused, so the blocked payments never get a label at all. A moderation queue only contains items an earlier model flagged, and user reports come from the people who noticed and bothered, which over-represents some kinds of users and some kinds of harm, in the way the baker only hears from the customers who come back.

This matters because a model trained only on labelled cases learns the boundary of the previous system. The standard remedy is to let a small random slice of payments through without blocking, perhaps one in a thousand, and label all of them, which gives an unbiased sample at the cost of some fraud deliberately allowed through. With 1 million payments a day, that slice is 1,000 payments, and at a 0.1 percent fraud rate it contains about one fraud a day, which is why these audit samples are small and precious.

When humans supply the labels, the label definition is a written policy and the reviewers are people applying it. Two reviewers shown the same borderline case will disagree some of the time, and the rate at which they disagree is a measurement of how unclear the policy is. Recording disagreements, resolving them, and tightening the policy where they cluster improves the labels before a model ever sees them. A measure such as Cohen’s kappa, which scores agreement after discounting the agreement two people would reach by chance, tells you whether the labels are dependable enough to train on.

People confuse ‘no dispute yet’ with ‘not fraud’, because a payment that is ten days old and quiet looks like a clean negative in a spreadsheet, although under a 60-day window its label is unknown. Treating it as negative puts recent frauds into the negative class, which is exactly the class the model is told to be relaxed about.

People also assume a drop in a metric on the newest data means the model got worse. If recall, the share of real frauds the model caught, is far lower on last week’s payments than on payments from three months ago, the usual cause is that last week’s disputes have not arrived yet, so the positives are missing and recall is measured against an incomplete answer key. Compare cohorts of the same age before concluding anything about the model.

A human label gets treated as ground truth, the certain right answer, when reviewers get tired and policies have grey areas. A human label is better evidence than a proxy, but it still has a source and a delay, and both belong next to it in the dataset.

The last confusion is forgetting that the cases which reach reviewers were chosen by an earlier model or a rule. Their labels describe the payments the current system already suspected, so a model trained on them alone learns where the old boundary was, which is the reason the random slice in the section above exists.

Interviewers like to interrupt the pipeline sketch to ask where the labels come from, and the answer with its follow-ups fills three to five minutes of the data part of the interview. Introduce them in one sentence as soon as you have named the prediction, for example ‘the label is a confirmed chargeback, which arrives up to 60 days later, so I would train on mature cohorts and keep an unresolved state for recent payments’. That sentence covers the source, the delay and the unresolved case, which are the three things the follow-ups probe.