Where mule detection sits in the timeline

Start with two clocks

Application controls run before an account or facility is approved. Mule detection usually becomes stronger after onboarding, when money starts to move and behavioural patterns form. The clocks overlap, but they do not begin with the same evidence.

This distinction matters because a control can be effective and still arrive after a loss path has opened. Transaction monitoring may identify a receiving account from its flows. An application-time control asks whether the actor behind the opening record was coherent before those flows existed.

The Indian Cyber Crime Coordination Centre reported 32.08 lakh layer-1 mule accounts shared through the i4c suspect registry as of 30 June 2026. That figure establishes the operational scale of post-onboarding action. It does not state how many accounts could have been identified at application time.

Before opening: identity and control evidence

At application time, the institution has submitted identity attributes, authentication results, device context and whatever history it is permitted to use. There may be no transaction graph yet. A new merchant or deposit account can be behaviourally blank because it has not operated.

The useful questions concern coherence and reuse. Does one device appear across unrelated applications? Does a beneficiary or address connect to a recent ring? Is the mobile number stable enough to support the claimed history? Are there contradictions between the applicant's records and the infrastructure controlling the session?

An application-time score should return a reasoned action. It should not claim to know future account behaviour. Its job is narrower: identify when the opening record lacks a credible independent actor or connects to known application infrastructure.

At opening: preserve the baseline

Once the account opens, the original evidence should become a baseline. Device changes, contact changes, beneficiary additions and new graph links can then be evaluated as changes rather than isolated events. That preserves the difference between an ordinary update and a coordinated handoff.

The RBI KYC Master Direction requires ongoing due diligence and periodic KYC under defined risk categories. A personhood change set can help route review inside those processes. It does not alter the institution's regulatory responsibility or substitute a vendor score for its judgment.

After money moves: mule behaviour becomes observable

Transaction monitoring sees evidence that did not exist at application time. Rapid incoming transfers, unusual counterparty concentration, short holding periods and coordinated dispersal can change the account's risk. Those observations concern operation of the account, not only the identity record used to open it.

The Reserve Bank Innovation Hub describes MuleHunter.AI as analysing account and transaction behaviour to identify suspected mule accounts. The Ministry of Finance reports that it is operating across 26 banks. The system belongs in the post-onboarding control layer because its evidence depends on account activity. That position is a strength, not a defect.

The Department of Telecommunications reports that the Financial Fraud Risk Indicator is used by more than 1,000 banks, third-party app providers and payment system operators as of 22 December 2025. Telecom risk intelligence can inform several points in the timeline, including payment controls and account review. Institutions still need to define which decision consumes each signal.

The later control should teach the earlier one

A confirmed mule outcome is valuable application-time training evidence. The institution can look back at the original device, address, contact history and graph position, then ask which evidence was available before approval. That is a retrospective label, not permission to leak future events into a historical test.

The feedback loop must preserve dates. A feature observed after opening cannot be used to score the original application during a backtest. Doing so creates an impressive result that production can never reproduce. The model record should show the source time for every input.

Our view is that application scoring and mule detection should be measured as adjacent controls. One tests the opening actor. The other tests the operating account. A shared outcome store can improve both while their decision rights remain separate.

Reconstruct the evidence clock for each case

A confirmed mule case should carry more than one date. Preserve when the application was submitted, when the account opened, when the qualifying behaviour first appeared and when an investigator confirmed the outcome. Those moments let the institution ask which control could have acted and what action was available then. Collapsing them into one fraud date makes an application model look late or a transaction model look early without showing the evidence either system had.

The public descriptions of MuleHunter.AI and the Financial Fraud Risk Indicator also point to different evidence domains. Account behaviour and telecom risk can reach a decision at different times. The case record should retain the source, observation time, version and consuming policy for each signal. A current telecom verdict must not be inserted into an older application record unless the same verdict was available at that application time.

For retrospective review, start from the confirmed outcome and move backward through the dated record. Mark evidence that existed before opening, evidence created by account operation and evidence added during investigation. Then rerun each control using only its eligible set. This produces a fair comparison and shows where a new application rule may help. It also shows cases that could not have been identified before transactions began, which should remain credited to the later monitoring layer.

Detection latency is part of the control design

A post-onboarding alert can be timely for stopping further transfers even when it could not prevent account opening. An application alert can reduce exposure before opening while missing behaviour that becomes visible only later. Comparing the two with one detection-rate number erases the decision each control was built to support.

Measure time to actionable evidence. For an application control, that can mean the interval between submission and a reasoned recommendation. For transaction monitoring, it can mean the interval between a qualifying behaviour pattern and the case reaching an investigator. The clocks should be reported separately.

Loss prevention also depends on the action path. A fast alert that enters an unstaffed queue may have less effect than a later alert tied to a clear hold, review or escalation policy. Model latency and operational latency belong in the same evaluation report, but they are not the same measure.

Give each handoff an owner

Application fraud, KYC operations and transaction monitoring often sit in different teams. A linked timeline needs named ownership at the boundaries. Otherwise a personhood alert can be treated as somebody else's transaction case, while a later mule outcome never returns to the application model.

Define which system opens the case, which team can change the recommended action and which event closes the feedback loop. Preserve the original model recommendation separately from the human decision. That distinction allows audit teams to measure both the model and the policy applied around it.

Shared identifiers also need a governance boundary. Application and transaction teams may use the same tokenised entity graph while retaining different access to raw records. A graph connection should not become a reason to expose another team's customer data.

The result is one evidence timeline with separate decision rights. That is more useful than forcing every control into one vendor surface or one undifferentiated risk score.

A practical operating model

The sequence below gives each control a clear job. It also gives audit teams a way to ask whether a decision used evidence that actually existed at the time.

1. Application decision

   Run KYC, bureau and personhood controls. Preserve their separate results and reason codes.

2. Opening baseline

   Record the device, contact, graph and policy state that supported the approved action.

3. Behaviour monitoring

   Evaluate transactions and account changes under the institution's existing monitoring rules.

4. Outcome feedback

   Return confirmed mule and clean outcomes to dated model-development datasets under governance controls.