They need both, but neither is sufficient alone. Identity verification reduces fake or low-confidence onboarding, while transaction monitoring catches misuse that begins after the account exists. The practical priority is integration: identity confidence should influence payment friction, case handling, and escalation when transfer patterns become suspicious.
Why banks should treat mule fraud as an identity-and-transaction problem
Transaction monitoring and identity verification solve different parts of the same fraud chain. Verification reduces the chance that a mule account is opened with weak, synthetic, or spoofed credentials, while monitoring is what exposes suspicious behaviour after the account is active. For banks, the practical question is not which one replaces the other, but how strongly identity confidence should shape downstream transaction controls.
The answer matters because mule activity often starts cleanly and only becomes visible once funds begin to move. That means onboarding controls, payment friction, and post-onboarding surveillance need to work as one control plane rather than as separate teams chasing different alerts.
What identity verification contributes that monitoring cannot
Identity verification is the front-end control. It helps banks decide whether the person opening the account is real, reachable, and consistent with the claimed identity, which is especially important where synthetic identities, deepfakes, or document abuse are used to create mule accounts. Strong onboarding checks reduce the pool of accounts available for later abuse.
That said, verification is only a confidence signal, not a guarantee. A legitimately verified person can still become a mule, be coerced, or sell access after onboarding. The control therefore needs to be calibrated to the risk at the point of account creation, not treated as proof that future activity is safe.
Why transaction monitoring remains essential after onboarding
Transaction monitoring catches patterns that identity checks cannot see: rapid in-and-out movement, structuring, unusual beneficiary chains, pass-through behaviour, and velocity spikes. Those patterns are often the first operational sign that an account has shifted from ordinary use to mule activity. Monitoring is also the layer that supports intervention once suspicious transfers begin.
In practice, monitoring becomes more effective when it uses identity confidence as an input. A low-assurance account may warrant tighter payment thresholds, faster review, or earlier escalation, while a high-assurance customer with normal behaviour may need less friction. Banks that ignore this linkage tend to over-alert on harmless activity or under-react to weakly verified accounts.
How to combine both controls in a usable banking model
The strongest model is tiered, not binary. Identity verification should influence initial risk scoring, payment limits, and the threshold for step-up review, while transaction monitoring should continuously reassess whether observed behaviour matches the original onboarding profile. That integration is what turns two partial controls into one practical fraud defence.
For banks handling mule risk, the most useful operating pattern is to let onboarding quality and transaction behaviour reinforce each other. A customer who clears weak verification but then shows pass-through activity should be treated differently from a customer with strong verification and ordinary payment patterns. The decision should be based on combined confidence, not on whichever control generated the latest alert.
Risk and Threat Considerations
When banks over-rely on either control alone, mule fraud shifts to the weakest point in the lifecycle. Weak verification allows bad accounts to enter the system, while weak monitoring lets those accounts be used long enough to move funds and frustrate recovery.
Failure mechanism: Fraudsters exploit gaps between onboarding and activity review, using verified or semi-verified accounts as temporary transit points until suspicious flows become visible.
Impact: Losses increase, recovery gets harder, and the bank may face higher AML workload, poorer case quality, and faster spread across linked accounts or beneficiaries.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Banks verify external customers before account use. |
| IA-5 — Authenticator Management | Mule accounts often depend on compromised or weak authenticators. | |
| Recommendation — Use IA-8 to strengthen customer identity assurance at onboarding. Apply IA-5 to control credential issuance, rotation, and recovery. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | The question hinges on balancing identity assurance with access decisions. |
| DE.CM-01 — Networks and systems are monitored to detect potential cybersecurity events | Transaction monitoring is the detection layer for mule behaviour. | |
| Recommendation — Tie identity confidence to access and payment friction decisions. Use DE.CM-01 to detect suspicious payment patterns and escalation triggers. | ||
| OWASP ASVS | V6 — Authentication | Identity verification and account opening assurance depend on strong authentication controls. |
| V8 — Authorization | Payment friction and escalation depend on permission and risk-based access decisions. | |
| V16 — Security Logging and Error Handling | Monitoring mule fraud depends on useful logs and alert fidelity. | |
| Recommendation — Apply V6 to harden identity assurance flows and step-up checks. Use V8 to align transaction permissions with verified risk levels. Use V16 to retain logs that support fraud detection and case review. | ||
| CIS Controls v8 | CIS-5 — Account Management | Mule fraud is reduced by controlling account creation and lifecycle. |
| Recommendation — Apply CIS-5 to manage account creation, review, and removal tightly. | ||
| MITRE ATT&CK | T1589 — Gather Victim Identity Information | Fraudsters often assemble identity data to create convincing mule accounts. |
| Recommendation — Map identity-abuse patterns to ATT&CK and tune detection for account creation abuse. | ||
Practitioner Guidance
What to prioritise: Treat identity confidence as an upstream risk input to payment controls, not as a one-time onboarding checkbox. When verification quality is weak, lower the threshold for step-up review and suspicious-activity escalation.
What to verify: Confirm that fraud, AML, and onboarding teams are using the same customer risk view, the same escalation rules, and the same feedback loop from confirmed mule cases back into detection logic. If those signals are siloed, neither control will perform well.
Decision rule: If an account shows strong transaction anomalies but low onboarding assurance, escalate faster than you would for either signal alone. If onboarding assurance is high, do not downgrade monitoring, because mule behaviour is usually revealed by movement patterns, not by identity quality alone.
Practitioner takeaway: The right priority is not transaction monitoring versus identity verification, but how confidently the bank can connect who opened the account with what the account later does.
Related resources from NHI Mgmt Group
- What is the difference between identity verification and transaction monitoring in fraud prevention?
- Why does identity verification at onboarding reduce account-opening fraud more effectively than waiting for login or transaction monitoring?
- Should fraud teams separate identity verification from transaction monitoring?
- Why do real-time transaction monitoring and identity verification need to be connected in modern banking?