The money has to leave somewhere.

Fictional scenarios and synthetic data. Reviewed 6 November 2026.

A Lagoon Casino account opened four days ago. Six card deposits totalling 1,900, from three cards issued in two countries. Forty minutes of play, net loss 60. Now a withdrawal request for 1,840 to a bank account in a third country, in the account holder's name. The operator's payments desk has the request in a queue with a four-hour service level. Tomas at Northbank Pay has the deposits in an export and can see something the payments desk cannot: the first four deposit attempts, on two other cards, were declined.

What is actually being decided.

The decision is whether to send 1,840 to a destination that has never been used to fund this account, now, and what is a proportionate thing to ask first. The operator carries the loss if the deposits are later disputed by cardholders who never heard of Lagoon, because a later card dispute does not automatically reverse a separate payout; recovery depends on its rail and circumstances. The PSP carries the payout rail and, if the pattern repeats across a merchant, a conversation with the acquirer. The account holder, if the three cards are theirs, carries a delay on money that is theirs.

Three readings of the same four days.

Deposit, minimal play, withdraw to a different method has at least three honest explanations, and the desk's job is to keep all three alive until the evidence narrows them.

The first is cash-out of stolen card credentials: deposits on cards the account holder does not own, a token amount of play to look like a customer, and a withdrawal to an account the holder controls. OWASP's catalogue of automated threats lists cashing out (OAT-012) as the conversion of stolen payment credentials into money or goods, and a gambling account with a flexible withdrawal method is a conversion route. The disputes arrive weeks later, from cardholders, and land on the operator.

The second is movement of funds whose origin is the problem rather than the card. FATF's published typology material, including its work on the casino and gaming sector, describes accounts used to pass money through with little or no genuine play. We say no more about method than that; the defender-side signature is the same low ratio of play to volume, with the difference that the cards may well belong to the account holder.

The third is a person. Someone who deposited by card because that was the fast option, lost a little, decided this was not for them, and wants the money in their bank because a refund to the credit card would sit against a balance already paid. This person exists, and the cost of treating them as the first reading is a complaint, a one-star review and, sometimes a dispute of the deposits raised out of frustration, which warrants investigation rather than automatically establishing first-party misuse.

The closed-loop rule and where it leaks.

The most useful single control in this area is a rule that money leaves by the route it arrived, up to the amount it arrived by. Deposits of 1,900 from three cards; withdrawals up to 1,900 go back to those three cards in proportion; anything above that, which can only be winnings, goes to a verified account in the holder's name. The rule's value is in the first reading: a withdrawal that returns to the cardholder gives the cash-out nothing, which removes the reason to deposit at all.

The rule leaks at its exceptions, and the exceptions are where the risk returns. Some deposit methods cannot receive a credit; some cards are prepaid or expired by the time the withdrawal is requested; some operators allow a holder to nominate a bank account once documents are supplied. Each exception is reasonable on its own, and each is, from the point of view of someone planning the first reading, the whole point. Every exception should be a decision with an owner and a log line, not a default the payments desk applies when the card declines a credit.

What the PSP sees.

In the Northbank export the request is a row with a merchant reference, an amount, a destination type, and a flag for whether the destination matches any prior deposit instrument. Beside it sit the deposits: six approvals and four declines, the declines carrying do-not-honour and insufficient-funds codes on two further card references that never succeeded. Five card references in four days on one account. Issuer countries for the approved cards do not match the destination bank's country, and neither matches the synthetic country label in the exercise. The 203.0.113.0/24 address range is documentation-only and has no real geolocation.

Those are observations. The inference, that the deposits were made on cards the holder does not own, is now stronger than before, mainly because of the declines: a person using their own cards does not usually try five. The alternative we keep alive is an expatriate with cards from two countries, one of which had a low limit that evening. It covers the issuer countries. It covers the declines poorly.

The source-of-funds question.

When the loop cannot close and the evidence points to the first or second reading, the operator has one question left, and how it is asked decides whether a real customer stays. A generic demand for "proof of funds" is slow, vague and insulting. A specific question is quicker and more informative: "Three cards were used to fund this account. Can you confirm each is in your name, and show us the statement line for the deposit of 400 on the 3rd?" A real holder can answer in a day. Someone using others' cards cannot answer at all, and usually does not try.

Time is the other lever. A dispute on a deposit arrives in its own time, typically weeks after the authorisation, as the Volume 01 note disputes and time sets out. A payout sent today is gone before the dispute exists. The hold is the operator's only moment of control, so the hold should be set in hours with a review, not left open, and not skipped.

A failure mode to watch.

Paying out to a new destination because the deposits "were authorised" and the account "passed KYC". An authorisation says the issuer approved the transaction; it does not say the cardholder did. A KYC pass says the documents and the face matched; it does not say the cards belong to the face. Both facts are true and neither is the fact the payout needs. The opposite mistake, holding every withdrawal by default, converts real customers into complainants and, over a quarter, into a dispute ratio.

A way to work it.

1. Write the request as a sentence: account age, deposits by instrument with approvals and declines, play as a share of volume, destination and whether it matches a deposit instrument.
2. Apply closed loop first. Route whatever can go back to the deposit instruments, and reduce the open question to the remainder.
3. For the remainder, pull issuer country, destination country and IP country, and count the mismatches. Write them as observations.
4. Decide which of the three readings each observation supports and which it rules out. If the declines are there, say so; they carry weight.
5. Ask a source-of-funds question that names the instrument and the amount. Hold the payout for a fixed number of hours with an owner and a review time.
6. Log the exception if one is used, who approved it, and what would have changed the decision. Next quarter's exception review depends on it.

Take it to the desk.

For each exception you allow to the closed-loop rule, who asked for it, and what does the withdrawal look like when the exception is the whole point? Try it: Deposit and withdraw, and SIM-swap trader for the version where the destination changed in the same hour as the login. Look up: cash-out and mule account.

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.