In pay-as-you-go device financing, the phone is the collateral. A customer walks out with a smartphone they couldn't otherwise afford, and they pay for it in small installments over the following months. The thing that makes the whole model work, the reason a lender can extend credit to someone with no formal credit history, is that the device itself can be locked if payments stop. Miss enough installments and the screen goes dark until you pay.

That control is the entire risk model. Which means the most valuable thing an adversary can do is take it away.

A "hack event," in our world, is exactly that: someone compromises the device so it can keep working while the lender's control over it quietly stops working. The customer keeps a fully functional phone. We keep an asset we can no longer lock, on a loan that's no longer being paid. The collateral is still in someone's hand but it just isn't collateral anymore.

Detecting these events, early and precisely, is one of the least glamorous and most important problems in this business. Here's how I think about it.

The problem isn't detecting failure. It's detecting deception.

A device that stops paying is easy to see. The hard part is that "stopped paying" has many innocent explanations. The phone broke. It was lost or stolen. The customer travelled and went offline. They hit genuine hardship and simply can't pay this month which is a person to help, not a fraudster to chase.

A hack event hides inside that noise. From a distance it looks like just another default. Up close, it has a different signature: the device is alive and being used, but the part of it that answers to us has gone quiet or started lying. Telling those two stories apart; hardship versus compromise is the whole game. Get it wrong in one direction and you let systematic fraud run. Get it wrong in the other and you treat a struggling customer like a criminal.

So the goal was never a single "is this hacked?" flag. It was a way to triangulate intent from behaviour.

Before any signal design, you have to decide what you're optimising, because in this problem the two ways of being wrong have wildly asymmetric costs, and one of them isn't measured in money.

A missed hack (false negative) costs you a device and the remaining loan; quantifiable by the recoverable OLB. A wrongful lock (false positive) costs you a customer's trust, a support escalation, potentially a regulatory complaint, and if it clusters in one region or income band a fairness problem that no recovery number can offset.

So I don't treat this as a single loss function to be freely traded. I treat wrongful lock as a hard constraint, a ceiling you commit to and do not breach and then maximise recovery.

Concretely, the scoreboard has four families:

• Model quality: precision and recall, PR-AUC (not ROC-AUC positives are rare and the negative class is enormous), calibration (a 0.8 score should mean roughly 80% of such cases are real), and above all detection lead time how early before the asset walks we can flag it. Lead time, not accuracy, is what converts a detection into an actual recovery.
• Business: avoided loss, incremental recoveries, reduced lock leakage (locks/actions issued that fail to land or get bypassed), and the portfolio level default delta the programme moves.
• Customer: wrongful lock rate (the constraint), complaint rate, NPS impact, time to resolution when we're wrong, and disparate impact across region and income proxy. That last one is non-negotiable: a detector that's 2% wrong overall but 8% wrong in one region isn't 2% wrong.
• Ops: investigation queue volume, average handling time, and cost per case because a detector that's brilliant but floods a team you don't have is a detector that doesn't ship.

If I could keep only one number on the wall, it would be wrongful locks/actions per confirmed catch. It encodes the whole ethical and commercial tradeoff in a single ratio.

Signal one: the payment cliff

Honest repayment behaviour is messy but continuous. People pay late, pay partially, catch up, slide again it wobbles. Compromise tends to look different. It's a cliff: payments that were tracking along a normal curve stop abruptly and completely, and stay stopped, with none of the partial-payment texture you see in genuine hardship.

A cliff on its own means nothing as a lost phone produces a cliff too. But a cliff is the timestamp that makes everything else legible. It gives you a moment to anchor to and ask: what did the device do around the time the money stopped? Most of the signal in hack detection isn't in any one stream. It's in the alignment between the payment cliff and what the hardware was doing on either side of it.