Synthetic Identities and Mule Accounts: Why KYC Alone Is No Longer Enough

Facephi has published research on how mule accounts are increasingly opened using synthetic identities rather than stolen ones, and on the signals that can help detect them. It is worth reading in full. What we want to add is the architectural consequence for banks and payment providers, because it is uncomfortable: the way most institutions have separated identity from monitoring is the weakness being exploited.

What is a synthetic identity?

A stolen identity impersonates someone who exists. A synthetic identity does something subtler. It assembles a plausible person out of parts, some real, some invented, some borrowed from more than one source. Nobody reports it stolen, because there is no victim to notice. It has no complaint history, no disputed transactions, and no contradicting behaviour anywhere else in the system.

That is why it survives controls designed to validate attributes. The data checks out. The person does not exist.

What is a mule account?

A mule account is a conduit. Its purpose is to receive funds and pass them onward quickly enough, and through enough hops, that the connection between the victim and the beneficiary becomes hard to reconstruct.

The valuable property of a mule account is ordinariness. An account that behaves strangely from day one is easy to catch. An account that opens cleanly, sits quietly, receives a salary-shaped credit or two, and only becomes a conduit months later is not.

Why onboarding-only KYC can be insufficient

Most onboarding stacks were designed around a single question: is this identity genuine at the moment of application? Answer it well, and the account is trusted from then on.

That model has two problems. The first is that a synthetic identity is engineered to answer that question correctly. The second is more fundamental: a correct answer at onboarding says nothing about who is operating the account eighteen months later. Accounts get sold. Customers get recruited. Credentials get compromised. Genuine customers become mules without ever changing a single onboarding attribute.

Identity is a lifecycle, not an event

The more useful framing is that identity assurance decays. It is high immediately after a verified, biometric-backed onboarding, and it erodes with every change of device, every unusual session, every behavioural shift and every period of dormancy followed by sudden activity.

Continuous verification is not about re-onboarding customers every quarter. It is about being able to answer a second question alongside the first:

• Is this identity genuine?
• Is this account still behaving like the genuine customer we originally verified?

From identity intelligence to transaction intelligence

Architecturally, the two questions belong on the same chain of evidence.

Each layer contributes context the next one needs. An identity decision without device context cannot tell you that thirty accounts were opened from the same handset. A transaction alert without identity context forces an investigator to reconstruct the customer from scratch. A behavioural signal with neither is a curiosity.

Where institutions separate these systems, they usually separate the teams too, and then the data. The result is not that the signals are missing; it is that nobody can see them together in time to act.

Why behavioural signals matter

Behavioural intelligence covers a wide range of signals, and no single implementation uses all of them. Depending on the platform and the regulatory context it can include how a session is navigated, how data is entered, relationships between devices and accounts, changes in customer patterns over time, and the shape of transaction activity relative to the account history.

Two cautions. Behavioural signals are probabilistic, so they belong in scoring and prioritisation rather than in unilateral account closure. And they are personal data, so consent, purpose limitation, retention and transparency have to be designed in, not retrofitted.

Where AI genuinely helps, and where it does not

AI can help correlate weak signals that no analyst would connect manually, prioritise a queue so the highest-risk cases surface first, and identify emerging patterns before a rule exists for them. Those are real gains.

What AI does not do is remove the need for investigation, governance and evidence. A model that flags an account cannot explain itself to a regulator; a case file can. We would encourage institutions to treat AI as assistance that raises the quality of human decisions, and to invest as heavily in the surrounding operating model as in the model itself.

The AO perspective

AO works at the integration layer of this problem. Our view of the target architecture is deliberately sequential:

Identity capability such as Facephi, real-time monitoring in the payment flow, and behavioural intelligence in the customer relationship each solve a different part of it. The value appears when they share context. That is an architecture and integration problem before it is a product problem, and it is the work AO does: designing the flow, integrating the platforms, mapping the data, and building the operational tooling investigators actually use.

We are describing an architecture AO can design and integrate for a bank, not a single packaged product. Explore Connected Banking, AO Transaction Monitoring, Behavioural Banking or our Identity and eKYC capability for the component parts.

Related reading

Our commentary on what Tazama 4.0 means for real-time fraud and transaction monitoring covers the monitoring half of this chain in more depth.