IGA for core banking fraud prevention: where access fails

At a glance

What this is: This is an analysis of how identity governance and administration reduces internal fraud risk in core banking by tightening access lifecycles, separating duties, and making high-risk entitlements visible.

Why it matters: It matters because the same governance failures that enable banking fraud also weaken NHI, autonomous, and human access programmes wherever privileged access outlives its purpose.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes

👉 Read SecurEnds's full analysis of IGA for core banking fraud prevention

Context

Core banking systems concentrate sensitive financial actions in one place, so access governance failures quickly become fraud risk. In practice, the problem is not just privilege, but persistence: access is granted for a task, then left in place after the task changes or ends.

Identity governance and administration is the discipline that keeps those access decisions current. In a banking environment, that means connecting approvals, reviews, segregation of duties, and deprovisioning to the actual lifecycle of a role, vendor, or account.

The article’s core point is that prevention matters more than post-transaction detection. When access to move money, change records, or approve exceptions is already legitimate on paper, monitoring alone cannot stop the misuse path that governance should have closed earlier.

Key questions

Q: What breaks when access governance is weak in core banking systems?

A: Weak governance leaves standing privileges, overlapping duties, and forgotten vendor access in place long enough for misuse to look routine. The result is not just more risk, but a larger fraud surface inside systems that control money, records, and approvals. Banking teams should treat stale access as the failure condition, not the transaction that exposes it.

Q: Why do core banking roles need stricter access reviews than ordinary application roles?

A: Core banking roles can affect balances, approvals, adjustments, and audit trails, so a single permission often carries direct financial impact. When reviews are infrequent, the original business reason is lost and excess access becomes normal. Stricter review is justified because the consequence of a missed entitlement is materially higher.

Q: How do organisations know whether segregation of duties is actually working?

A: Segregation of duties is working only if no identity can combine enough permissions to complete the full banking workflow without an independent check. The test is not whether a policy exists, but whether cross-system role combinations are blocked before they create an end-to-end abuse path. If combinations are still possible, the control is only documented, not enforced.

Q: Who is accountable when vendor access remains active after a banking engagement ends?

A: Accountability should sit with the business owner, the system owner, and the identity governance process that failed to revoke access when the relationship ended. If no one owns offboarding, third-party access becomes a standing exposure. The control objective is to align access removal with contract closure, task completion, and evidence retention.

Technical breakdown

Standing privilege in core banking systems

Standing privilege means access remains active beyond the moment of need. In core banking, that creates a wide trust window because users can continue to initiate transactions, alter records, or approve exceptions long after the original business need has passed. The technical problem is not just excess entitlement, but entitlement that is no longer tied to current purpose, ownership, or review. Once access becomes persistent, it blends into normal operations and loses scrutiny. That makes misuse easier without requiring any system failure or exploit chain.

Practical implication: treat long-lived privileged access as a governance defect and force lifecycle-based review before it becomes invisible.

Segregation of duties across banking workflows

Segregation of duties is meant to prevent one identity from controlling an end-to-end financial process. In core banking, the risk appears when one role can initiate, modify, approve, and reconcile the same activity across different systems. The failure is often cross-platform, not within a single application, because workflow fragments can be combined into a complete abuse path. If SoD is only checked locally, overlaps slip through. Banking fraud often succeeds when multiple individually valid permissions are never assessed together as one control boundary.

Practical implication: evaluate toxic permission combinations across the full banking workflow, not system by system.

High-risk entitlements and auditability

High-risk entitlements are the small set of permissions that can materially change financial outcomes, such as overrides, backdated updates, reversals, and beneficiary creation. These permissions need separate handling because they carry disproportionate fraud potential. Auditability matters because banks must show who approved what, when, and under which policy. If access decisions live in email, spreadsheets, or local admin memory, the control may exist in theory but not in evidence. Governance becomes weak the moment it cannot be proven.

Practical implication: classify high-risk entitlements separately and maintain evidence at the point of approval, review, and removal.

Threat narrative

Attacker objective: The objective is to abuse trusted banking access to move money, alter records, or conceal activity without triggering immediate control exceptions.

1. Entry occurs through legitimate access that was granted for operations, support, audit, or vendor work and then left active after the original need changed.
2. Escalation happens when standing privileges, broad roles, or overlapping entitlements let the insider initiate, modify, or approve sensitive banking actions without a second check.
3. Impact is realised through unauthorised transfers, record changes, reversals, or account manipulation that look legitimate at the transaction layer but are abusive at the governance layer.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salt Typhoon US telecoms breach — Salt Typhoon APT used stolen credentials and Cisco CVE to breach US telecoms.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Core banking fraud is a lifecycle failure before it is a transaction failure. The article is right to centre access that outlives its purpose, because that is where internal misuse usually begins. When banking teams focus on detection without closing the access lifecycle, they preserve the exact conditions fraud depends on. The practitioner conclusion is straightforward: access must be governed as a living entitlement, not a one-time approval.

Standing privilege creates identity blast radius in banking environments. Once elevated access remains active across systems, a single identity can touch initiation, approval, and reconciliation paths that should never converge. That is not just excess privilege, it is a widened blast radius that makes normal operations indistinguishable from abuse. The practitioner conclusion is to measure which identities can still do too much across the core workflow.

Separation of duties fails when banking roles are evaluated in isolation. The article shows that fraud often emerges from combinations of permissions that look harmless individually. This is why SoD has to be enforced across the transaction chain, not inside a single application or team boundary. The practitioner conclusion is to test permission combinations the way a fraudster would, across the full process path.

Vendor access without lifecycle offboarding is a named governance failure, not a generic risk. The article highlights how third-party access can remain active after the work ends, which means accountability has outlived the business relationship. That failure mode is specific enough to audit and specific enough to prevent recurring. The practitioner conclusion is to track third-party entitlements against contract and task closure, not just ticket approval.

IGA becomes effective when it makes access review decisions economically meaningful. Quarterly certification alone is too slow for banking roles that change often and carry high fraud value. The article’s real contribution is showing that governance must be risk-tiered, continuously informed, and tied to operational ownership. The practitioner conclusion is to reserve more frequent scrutiny for the entitlements that can directly move or alter money.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• The same research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For a broader breach lens, see The 52 NHI breaches Report for patterns that map access persistence to real compromise paths.

What this signals

Access persistence is the common failure mode across banking fraud, NHI sprawl, and autonomous delegation. When identities are trusted longer than their purpose, governance loses the ability to distinguish legitimate use from abuse. For teams building controls now, the signal is clear: lifecycle enforcement matters more than another layer of post-event monitoring.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, entitlement excess is already the baseline condition in many environments. That makes banking fraud prevention a useful proxy for broader identity governance maturity, because the same pattern appears when service accounts, scripts, and automated workflows are left with too much authority.

Identity blast radius should become a board-level metric. If one identity can still initiate, approve, and reconcile the same financial process, the governance model is not preventing misuse, it is documenting it. Teams should use this topic to re-check where access review cadence, SoD enforcement, and offboarding really intersect in practice.

For practitioners

• Map core banking toxic combinations Review permissions across initiation, approval, adjustment, reversal, and reconciliation paths as one workflow. Flag combinations that let a single identity complete the full transaction chain.
• Reclassify high-risk entitlements Give overrides, backdated changes, beneficiary creation, and reversal rights separate governance handling with tighter approvals and more frequent recertification.
• Tie deprovisioning to role change events Connect HR and joiner-mover-leaver triggers so access is removed when responsibility changes, not after a delayed manual review.
• Audit vendor access against contract end dates Compare third-party entitlements to active support windows, task completion, and offboarding records so contractor access does not persist by default.
• Preserve evidence at the point of decision Record approvals, exceptions, and removals in a traceable control system so regulators and auditors can see why sensitive access existed.

Key takeaways

• Internal banking fraud often succeeds because access stayed active after the need for it ended, not because the system was technically broken.
• The article’s strongest evidence is that standing privilege, weak segregation of duties, and delayed offboarding create a fraud path that looks legitimate at transaction level.
• Banks that want prevention, not just detection, need lifecycle-linked access governance, enforced SoD, and evidence captured at the point of decision.

Key terms

• Standing Privilege: Standing privilege is access that remains active beyond the immediate need for it. In banking, it becomes risky when elevated permissions are left in place after a task, role, or vendor engagement ends, allowing actions that no longer match current responsibility.
• Segregation Of Duties: Segregation of duties is a control that prevents one identity from controlling too much of a business process. In core banking, it is meant to stop a single user from initiating, approving, and reconciling the same transaction path, whether the identity is human, service-based, or delegated.
• High-Risk Entitlement: A high-risk entitlement is any permission that can materially change money movement, records, approvals, or audit evidence. These rights need separate review because they carry more fraud potential than routine access, especially in systems where a small action can have direct financial impact.

Deepen your knowledge

Core banking access lifecycle and segregation of duties are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for privileged access, vendor accounts, or service identities, it is worth exploring.

This post draws on content published by SecurEnds: how IGA prevents internal fraud in core banking systems. Read the original.