Who is accountable for trusted digital identity when mobile operators support banks and other relying parties?

Accountability is shared, but mobile network operators carry a central role because they hold customer, device, and network data and often act as identity providers. Relying parties such as banks still own their authentication decisions, yet they depend on the operator’s identity proofing and fraud controls. Clear governance is needed so responsibility does not blur across the ecosystem.

Why Accountability Splits Across the Identity Chain

When mobile operators support banks and other relying parties, accountability is shared but not diluted. The operator usually performs proofing, device binding, and network-based risk checks, while the bank still decides whether to trust the signal and complete authentication. That means the operator is accountable for the quality of the identity evidence it produces, and the relying party is accountable for how it consumes that evidence.

This division matters because trusted digital identity fails when parties assume someone else is owning the control. NHI Management Group’s research shows that 92% of organisations expose NHIs to third parties, which is a useful reminder that shared ecosystems create shared exposure, not shared immunity. The same pattern appears in consumer and enterprise identity flows when operators, banks, and fraud teams all touch the same assurance chain. See the Ultimate Guide to NHIs and the 52 NHI Breaches Analysis for how external trust relationships become breach paths.

Practitioners often get this wrong by treating identity assurance as a contract term instead of an operational control boundary. In practice, many security teams discover the ambiguity only after a fraud event has already tested the handoff between issuer and relying party.

How Shared Trust Should Work in Practice

Good governance starts by separating three responsibilities: identity proofing, trust decisioning, and acceptance of authentication outcome. The mobile operator should define and evidence how it verifies subscriber identity, binds device or SIM signals, and detects fraud indicators. The bank should define what assurance level it requires, what signals it trusts, and when it will step up, reject, or re-check a login or transaction.

That division maps well to established control thinking. NIST SP 800-53 Rev 5 Security and Privacy Controls supports allocating accountability to the party operating each control, while eIDAS 2.0 reinforces the need for roles, assurance, and relying-party responsibility in federated identity ecosystems.

• Define the assurance contract in writing: what evidence the operator provides and what the bank can rely on.
• Track provenance for identity data, device signals, and fraud telemetry so disputes can be investigated.
• Set revocation and incident notification obligations for compromised subscriber records or device bindings.
• Require the relying party to document acceptance criteria, not just consume the operator’s result.

This is also where NHI discipline is useful. Identity signals and API credentials used between ecosystem participants should be treated as secrets with lifecycle controls, not as informal integration glue. The operational lesson is the same as in NHI governance: if ownership is unclear, revocation and escalation both become slower than attackers. These controls tend to break down when multiple jurisdictions and telecom-to-bank federation layers introduce different legal definitions of “identity proofed” and “trusted.”

Where the Model Breaks Down and What to Watch

Tighter assurance agreements often increase integration cost and operational overhead, so organisations have to balance stronger trust guarantees against customer friction and support complexity. There is no universal standard for this yet across all telecom and banking use cases, especially where identity proofing is reused across products and markets.

The biggest edge case is when an operator supplies only a risk signal rather than a formal identity assertion. In that model, the bank may over-trust a useful fraud indicator and under-document the fact that it still owns the final decision. Another common gap appears when third-party aggregators sit between the mobile operator and the relying party, which makes provenance, liability, and incident response harder to trace.

Security teams should also be careful not to confuse authentication strength with accountability. A strong signal does not remove the relying party’s duty to validate context, and a weak signal does not absolve the operator of poor proofing or slow revocation. If the ecosystem cannot answer who can revoke what, who notifies whom, and who records the evidence, the trust model is too vague to be operationally safe.

Related resources from NHI Mgmt Group

• Who is accountable when a digital identity programme handles age verification and other regulated checks incorrectly?
• Who is accountable for AML compliance when businesses delegate due diligence tasks to third parties?
• Who should be accountable for external identity lifecycle management across business and IT teams?
• Who should be accountable for identity data accuracy when HR, SIS, CRM, and IAM all touch the same record?