A person who passes every check and does not exist.

Fictional scenarios and synthetic data. Reviewed 6 November 2026.

Ines has a list from Lagoon Casino: sixty accounts opened over three weeks, every one of them through the operator's onboarding flow, every one of them with a KYC result of "pass". The operator's compliance lead is confident. The accounts have documents, matched data, a liveness result. Ines has the same sixty rows in a Northbank Pay export, and in that export forty-eight of them are funded by six cards.

What is actually being decided.

The decision is what weight to give a KYC pass when other evidence points the other way, and who is allowed to reopen the question. The operator carries the regulatory obligation and the cost of unwinding accounts it has already accepted. The PSP carries a deposit stream it may later be asked to explain, and a payout it may be asked to return. The forty-eight accounts, if they belong to forty-eight people, carry the indignity of being asked again.

FATF's published recommendations frame customer due diligence as a risk-based and continuing process rather than a single gate at the door. That framing matters here, because the question "does this person exist" is not one that a single gate can answer.

A pass is a list of narrow answers.

It helps to write down what each check in the onboarding flow actually tested. A document check tests whether an image is consistent with a genuine document of that type. A data check tests whether a name, date of birth and address match a record somewhere. A liveness check tests whether a live face was presented and matched the document image. Each is an observation about one artefact at one moment.

The inference most teams draw, that one real, single person owns the account and no other account, is not what any of those checks tested. A synthetic identity, in the sense we use it, is an identity assembled so that each artefact passes its own check while the combination corresponds to no one, or to someone who has no idea the account exists. We do not describe how such identities are assembled. The defender needs only this: individually valid artefacts can be combined, and the check that would notice the combination is not a document check.

Identity shows in the aggregate.

Where a synthetic account becomes visible is in company. A synthetic illustration from the Lagoon file. Sixty accounts, sixty passes. Forty-eight of them deposit from six cards, which in the Northbank export appear as BIN plus last four, each card touching eight accounts. Thirty-one of the sixty were opened between 02:00 and 04:00 on their respective days. The recovery e-mail addresses are constructed the same way, a first name and four digits at example.com. Those are observations.

The inference, that a small number of people control the sixty, is reasonable. The alternative explanations we keep alive are specific. A household can share a card. A prepaid product can put the same BIN in many hands, though not the same last four. Night-time registration is ordinary for shift workers and for players in another time zone. None of these explains all three observations together, which is the point: a single shared attribute is a lead, and the article on link analysis sets out the discipline for turning leads into a finding without over-reaching.

Three countries on one account.

The PSP sees less than the operator, but it sees something the operator's onboarding flow does not look at. A Northbank export carries, for each deposit, the issuer country of the card, the IP at the time of the transaction and the merchant's stated customer country. For most customers the three agree. When they do not, each mismatch is a separate observation worth naming.

A client of Meridian FX with a stated residence in one country, cards issued in a second and an IP that resolves to a third is not thereby synthetic. Expatriates exist; so do corporate cards and travel. But a cluster of accounts that each show the same three-country pattern, and that each deposit a round amount in the first hour, is a cluster the operator did not see at onboarding, because onboarding did not have the deposits yet. This is the sense in which due diligence continues after the pass: the evidence that would have changed the answer arrives later.

Patience is part of the pattern.

A synthetic account behaves like a good customer for longer than an analyst expects. Modest deposits, ordinary play or small trades, no complaints, limits raised on schedule. The value of the identity is in the limits it earns and the withdrawal it eventually makes, which is why the glossary pairs this term with bust-out. The account that passed KYC in March is the same account in September; the pass is a dated observation about March. If your review process only reopens accounts when they do something alarming, patient accounts never come up for review, which is the behaviour they were built to exploit.

A failure mode to watch.

Re-running the same check harder. When a cluster looks wrong, the instinct is to ask the sixty accounts for their documents again. The documents will pass again, because they passed before, and forty-eight people who may or may not exist have been asked to do something while nothing has been learned. The question that needed asking was about the relationship between the accounts, and about the funding instruments, and only the operator and the PSP together hold that evidence. The Volume 01 lesson evidence before action applies with unusual force here.

A way to work it.

1. List the checks in your onboarding flow and, for each, the one narrow thing it tested. Keep the list visible when reading a pass.
2. For the cluster in question, write the shared attributes as observations: which cards, which contact points, which timings, which device references.
3. For each shared attribute, write the innocent explanation and ask whether it covers the cluster or only a few members.
4. Pull the three countries for each account from the PSP export and count the mismatches. Share the counts with the operator; they do not have them.
5. Scope the action to the cluster, keep it reversible, name an owner and set a review date: for instance, consider a narrowly scoped review where your authority and applicable rules permit it; document customer impact and a prompt review deadline.
6. Record what would change your mind, so the review on the set date is a decision and not a re-reading.

Take it to the desk.

What, in your records, would look different between forty accounts that each passed KYC and forty accounts that belong to forty people? Try it: Bonus multi-accounting, where the same question arrives with a welcome bonus attached. Look up: synthetic identity and linked entities.

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.