Three layers of a takeover.

Fictional scenarios and synthetic data. Reviewed 6 November 2026.

At 06:12 a Meridian FX client who has traded quietly for three years requests a password reset. At 06:31 the account logs in from a device reference the account has never produced. At 06:54 the withdrawal bank details are changed. At 07:10 a withdrawal for most of the balance is requested to the new account. Tomas has the four timestamps on one screen and a question: is this a client who bought a new phone and changed banks, or someone else holding the client's life?

What is actually being decided.

The decision is not whether to lock the account. It is whether to let one specific movement of money proceed now, and what to ask before it does. Three parties carry something. The operator carries the loss if the withdrawal goes to a stranger and the reputational cost if a loyal client is treated as one. The PSP, Northbank Pay in our world, carries a payout it cannot easily recall once sent. The client carries the friction of a hold and, if the account really has been taken, the whole balance.

A takeover is rarely visible in one place. It is visible where three layers of evidence disagree with what this particular account used to do. We take them in order.

Layer one: the session.

The session layer is what the authentication system can observe on its own: failed attempts before a success, a reset flow, the age of the token, the interval between actions. OWASP's catalogue of automated threats describes credential stuffing (OAT-008) as the mass testing of username and password pairs obtained elsewhere against a login endpoint. The defender-side signature it implies is a flood of attempts spread across many accounts with a low success rate.

A synthetic illustration. In one night, 1,000 login attempts arrive at Meridian FX from 203.0.113.0/24, spread over 940 distinct accounts. Twenty succeed. That is the observation. The inference, that the twenty successes are takeovers rather than returning clients, is strong but not certain: a shared office or a VPN exit can also put many clients behind one range. The alternative we keep alive is that a few of the twenty are real people whose login coincided with the flood.

Note what the session layer cannot tell you. It does not know whether the person who passed the reset is the person who opened the account. A reset that completed correctly is evidence that someone controlled the recovery channel at that moment, nothing more. OWASP's authentication guidance treats recovery as part of the authentication surface for exactly this reason.

Layer two: the device.

The device layer compares the device reference seen now with the references this account has produced before. "This device has never been seen with this account" is an observation. "This is not the client" is an inference, and a weak one on its own. New phones, browser upgrades, a laptop borrowed on holiday and a family tablet all produce a never-seen device for a perfectly ordinary person.

What strengthens the inference is not the novelty of the device but its company. A device reference seen for the first time on this account, which also appeared on four other accounts during the same night's flood, is a different observation from a device seen for the first time anywhere. The Volume 01 note on shared signals covers why the shared attribute is the lead, and the article on link analysis covers when a lead becomes a finding. We do not describe here how device references are built; the defender needs only to know that they can be shared, and that sharing is the signal.

Layer three: the behaviour.

The behaviour layer is what the account does after the login. this is where the takeover separates from the new phone. The sequence matters more than any single action: reset, new device, recovery e-mail changed, withdrawal method changed, withdrawal requested, all inside an hour. Each step on its own has an innocent reading. The compression of all of them into one session is the thing a client with a new phone may not normally do, though "almost" is doing work in that sentence.

The withdrawal destination is the most informative behaviour of all. A request to withdraw to a bank account or wallet that has never been used to fund this account is a different event from a request to the method that deposited. The closed-loop question, whether money should leave by the route it arrived, is the subject of deposits, withdrawals and cash-out. Here it is enough to say that a changed destination is the step at which the intruder's plan becomes visible and the operator's loss becomes real.

What the PSP sees is narrower than what the operator sees. In a Northbank back-office export, the morning's events at Meridian FX appear as a payout request: amount, a beneficiary flagged new, a merchant reference, perhaps an IP. Northbank cannot see the reset or the device. The operator holds most of the evidence, which is why the hold has to be the operator's decision and the PSP's question.

A failure mode to watch.

Treating one layer as sufficient. Teams that block on a new device alone interrupt every client who travels or upgrades, and they learn to switch the rule off after the complaints arrive. Teams that wait for all three layers to light up often find that the behaviour layer completed before anyone looked, and the balance is gone. The useful middle is to let the first two layers raise attention and let the third, the movement of money to a new destination, be the thing that is held.

A way to work it.

1. Write the four or five observations in order with timestamps, each as a plain statement of what the system recorded.
2. For each, write the innocent explanation beside it. If you cannot think of one, you have an inference, not an observation.
3. Compare against this account's own history, not the population: how often has this client changed devices, reset passwords or added a beneficiary before?
4. Hold the money movement that goes to a new destination. Leave trading, viewing and deposits open. Set a review time of hours, not days.
5. Step up through a channel the attacker is less likely to hold; if the recovery e-mail was changed in the same session, that e-mail is not the channel.
6. Record the outcome either way, so that next month's threshold work has a labelled case to learn from.

Take it to the desk.

For each of your takeover signals, which legitimate customer behaviour produces exactly the same observation, and what do you do to that customer? Try it: SIM-swap trader, and for the Volume 01 version of the problem, Account takeover. Look up: credential stuffing and step-up.

Edited 6 November 2026. Primary references are listed above; fictional scenarios are not claims about Antifrog customers or operating experience.

Fictional learning material. Any numerical examples are synthetic. Use only authorised, appropriately minimised records for workplace exercises; do not upload customer information to this learning site.