How should IAM teams and fraud teams divide responsibility for open finance risk?

How to split responsibility between IAM and fraud in open finance

Open finance risk is easiest to manage when IAM owns the controls that prove and constrain access, and fraud owns the controls that detect abnormal use after access is granted. That split works only if both teams treat the boundary as shared operating terrain, with common telemetry, escalation rules, and clear ownership for revocation when behaviour changes.

What IAM should own versus what fraud should own

IAM should own the identity lifecycle and the trust decisions that make open finance access possible: authentication, delegation consent, token issuance, session validity, entitlement changes, and revocation. Fraud should own behavioural detection, anomaly triage, case investigation, and recipient-risk analysis, because those functions answer whether the access is being used in a way that looks abusive, coerced, or inconsistent with the customer’s normal patterns.

The practical test is simple: if the control changes who can access what, or for how long, it belongs with IAM. If the control evaluates whether the access is being used in a suspicious way, or whether a payee, pattern, or transaction path looks fraudulent, it belongs with fraud. IAM can harden the gate, but it cannot by itself decide whether a technically authorised action is still safe to let continue.

Open finance programmes also need explicit ownership for exceptions. If a delegated consent is disputed, a token appears compromised, or a high-risk recipient is repeatedly used across accounts, IAM should be able to revoke or narrow access immediately while fraud decides whether the event is a confirmed abuse pattern, a false positive, or a wider campaign. That boundary is why the operating model matters as much as the technology.

Where the boundary breaks down in practice

The most common failure is assuming that consent or successful authentication equals safe activity. In open finance, a legitimate grant can still be abused through account takeover, social engineering, mule activity, or recipient manipulation. Teams that separate “access approved” from “behaviour safe” too rigidly end up with blind spots, especially when the same token can be used across many requests and many merchants or payees.

Another failure is split telemetry. IAM often sees authentication events, consent state, scope, and revocation status, while fraud sees device, channel, beneficiary, velocity, and pattern-change signals. If those views are not joined at decision time, neither team has enough context to act quickly. Useful operating models therefore share event feeds, case identifiers, and a single escalation path for high-confidence abuse.

What good operating models look like

Strong open finance governance uses a shared control plane with distinct decision rights. IAM handles grant, maintain, and revoke decisions for identity and delegation, while fraud owns continuous monitoring and abuse response. The two teams should meet on a small number of triggers: unusual beneficiary change, repeated consent failures, new device or channel risk, high-velocity payment initiation, and any sign that an authorised path is being used outside normal customer behaviour.

• IAM should be measured on access integrity, consent validity, revocation latency, and the completeness of delegation records.
• Fraud should be measured on detection quality, investigation turnaround, confirmed abuse rate, and the speed of escalating to access restriction.
• Both teams should be measured on how quickly they converge when a risky pattern crosses from suspicious to actionable.

Risk and Threat Considerations

Open finance concentrates risk at the point where legitimate delegated access can be turned into misuse. The security issue is not only account takeover, it is also the abuse of valid grants, because the attacker can operate inside apparently authorised rails while hiding behind normal authentication and consent flows.

Failure mechanism: A compromised or manipulated access path is allowed to keep functioning because IAM and fraud are treating grant control and behavioural monitoring as separate problems, rather than as linked stages of the same trust chain.

Impact: Organisations can miss fraudulent payment initiation, abusive recipient changes, and repeated misuse of delegated access until loss has already scaled across multiple sessions or accounts.

Practitioner Guidance

What to prioritise: Define a single ownership model for revocation and escalation before tuning detection thresholds. If an event can both invalidate access and indicate abuse, the runbook should say who acts first and what evidence must be passed across.

What to verify: Confirm that IAM telemetry and fraud telemetry can be joined on the same consent, token, account, recipient, and session identifiers. If analysts cannot reconstruct the full path from grant to use to revocation, the control split is not operationally sound.

Decision rule: If the issue is about whether access should exist, IAM leads. If the issue is about whether the authorised access is being misused, fraud leads. If both are true, treat it as a shared incident and route to immediate revocation plus behavioural investigation.

Practitioner takeaway: Open finance works best when IAM controls the permission boundary and fraud controls the misuse boundary, but neither team should own the whole problem alone.

Related resources from NHI Mgmt Group

• How should IAM and fraud teams handle write access in open finance?
• How should teams reduce the risk from overprivileged NHIs?
• How do IAM and fraud teams know when insider risk is moving from theory to loss?
• How should security teams divide responsibility between IAM and IGA?