Identity teams own how the user is verified, while fraud teams own how the transaction is assessed for coercion or impersonation. The gap appears when neither team owns the mobile interaction itself. A workable model defines shared escalation, shared telemetry, and a single decision path for suspicious approvals.
How the accountability split works in practice
Identity and fraud teams can share accountability without sharing the same decision. Identity owns the trust in the user, session, or device proofing path, while fraud owns whether the payment event looks coerced, replayed, or impersonated. The cleanest model is not a committee decision on every tap, but a single operating model that defines who can stop, step up, or approve when the signals conflict.
The operational boundary matters because mobile payment authorisation is a transaction, not just a login. A user may be authenticated well and still be under social engineering, device takeover, or mule-style pressure. That is why the handoff has to be explicit: identity provides the assurance inputs, fraud interprets behavioural and transactional anomalies, and both teams agree on when the transaction is escalated rather than silently allowed.
In practice, the shared model works best when the organisation defines one control owner for the end-to-end decision path, while preserving specialist ownership of the underlying signals. That usually means identity teams manage proofing strength, authentication friction, and device or session trust, while fraud teams manage transaction scoring, scam heuristics, and post-event review. The missing piece is the mobile interaction layer itself, where prompt design, consent capture, and approval UX can either surface risk or hide it.
Where the handoff fails in mobile authorisation
The most common failure is a gap between identity assurance and fraud detection. Identity can confirm that the user is real, yet the transaction can still be the result of coercion, authorised push payment style manipulation, or a compromised app session. Fraud can flag suspicious behaviour, but if the user journey does not surface the right challenge at the right moment, the risky approval still goes through.
Another failure is duplicated ownership of the same signal. If both teams think the other owns mobile device trust, step-up triggers, or suspicious approval handling, the organisation ends up with inconsistent controls and weak escalation. A payment decision should not depend on which team happens to see the alert first. Shared telemetry, common thresholds, and a single escalation route prevent that split-brain outcome.
For mobile payment flows, the interaction design is part of the control plane. If the app permits approvals with weak context, or if alerts do not show the amount, counterparty, and behavioural reason for the hold, users can be nudged into approving transactions they do not understand. The accountability model therefore has to cover not just identities and fraud scores, but the mobile approval experience itself.
What a workable operating model needs
A practical model starts with one agreed decision tree for suspicious approvals. Identity should own the steps that increase assurance, such as step-up verification, session revalidation, and device confidence checks, while fraud owns the conditions that divert the transaction into review, block, or customer contact. The two teams need the same event taxonomy so that a device change, a new payee, and a high-risk amount are interpreted consistently.
Telemetry should be shared at the event level, not trapped in separate dashboards. That means common identifiers for user, device, channel, session, payee, and transaction state, plus auditability of who overrode a block and why. The goal is not just detection. It is a decision record that can be reviewed after a disputed payment or suspected scam, without reconstructing the case from disconnected logs.
Accountability also depends on recovery logic. If the payment is paused, the organisation needs clear rules for escalation to the right team, customer contact, and, where needed, investigation of account or device compromise. Identity fraud prevention guidance is useful here because it treats device and behavioural signals as part of the fraud decision, not an afterthought. Authorisation models guidance also helps teams separate who may act from who should be trusted to act in a specific context.
Risk and Threat Considerations
When no team owns the mobile interaction layer, attackers and scammers can exploit the seam between trust in the user and trust in the transaction. The result is a control gap where a legitimate identity can be used to approve an illegitimate payment, especially when coercion, impersonation, or device compromise changes the meaning of a valid approval.
Failure mechanism: Identity assurance and fraud scoring are evaluated in different systems, so the approval path never receives a unified risk decision. The user sees a normal authorisation flow, while the organisation lacks a single point to stop or step up the transaction when signals conflict.
Impact: Coerced approvals, scam payments, and compromised-session authorisations can pass through as valid transactions, creating financial loss, dispute handling burden, and weaker post-incident attribution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 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-2 — Identification and Authentication (Organizational Users) | Mobile payment approval depends on verified user authentication before authorisation. |
| IA-5 — Authenticator Management | Shared accountability hinges on managing authenticators, sessions and step-up triggers safely. | |
| AU-2 — Event Logging | Shared telemetry and a single decision path require auditable payment and risk events. | |
| Recommendation — Enforce strong user authentication before allowing payment approval. Rotate, protect and monitor authenticators tied to payment approval flows. Log the full approval journey so identity and fraud teams can reconstruct decisions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Shared accountability needs clear ownership and lifecycle control for accounts used in approval workflows. |
| CIS-8 — Audit Log Management | A joint mobile approval model depends on logs that support fraud review and incident reconstruction. | |
| Recommendation — Track and review accounts that can initiate or approve payment actions. Centralise and retain logs for mobile payment approvals and escalation decisions. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Mobile payment approval APIs must prevent unintended users or roles from approving high-risk actions. |
| API1 — Broken Object Level Authorization | Transaction records and approval objects must be protected from cross-user or cross-session misuse. | |
| Recommendation — Verify that only the correct functions and roles can approve or override payments. Check that each payment object is accessible only to the rightful user and workflow. | ||
Practitioner Guidance
What to prioritise: Define one accountable owner for the end-to-end mobile approval journey, then assign supporting ownership for identity assurance and fraud decisioning. The practical test is whether an analyst can tell, from one workflow, who escalates, who blocks, and who records the final rationale.
What to verify: Confirm that the app emits enough shared telemetry to explain the decision after the fact, including user, device, session, amount, payee, and challenge outcome. If the organisation cannot reconstruct why a payment was allowed or stopped, the accountability model is still incomplete.
Decision rule: If the signal mix says “real user, risky context,” treat the case as a joint escalation rather than a pure identity problem or a pure fraud problem. If the same control is being measured by both teams, name one team as the decision owner and the other as the specialist contributor.
Practitioner takeaway: The goal is not to merge identity and fraud teams, but to make the mobile approval path answerable by one decision process, with clear escalation when user authenticity and transaction legitimacy do not line up.
Related resources from NHI Mgmt Group
- How should finance and identity teams share accountability for payment fraud?
- How should fraud, identity, and product teams share accountability for trust decisions?
- How do identity and fraud teams share accountability for delivery-platform abuse?
- How do identity teams and data security teams share accountability for on-prem exposure?