Notifications
Clear all
Topic starter
07/06/2026 8:03 pm
TL;DR: Internal banking fraud often begins with access that was granted for a valid reason and never removed, allowing standing privileges, weak segregation of duties, and fragmented oversight to create misuse paths across core systems, according to SecurEnds. The real control problem is not detection after the fact, but governance that keeps access current, limited, and accountable before misuse can occur.
NHIMG editorial — based on content published by SecurEnds: how IGA prevents internal fraud in core banking systems
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
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map core banking toxic combinations Review permissions across initiation, approval, adjustment, reversal, and reconciliation paths as one workflow.
- 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.
What's in the full article
SecurEnds's full article covers the operational detail this post intentionally leaves for the source:
- The 10 control patterns translated into banking-specific governance steps for fraud prevention
- The way SecurEnds frames access certifications, SoD enforcement, and lifecycle triggers in practice
- The audit and compliance angle for RBI, SOX, PCI DSS, and ISO 27001 reporting
- The vendor's own workflow examples for core banking, support teams, and third-party access
👉 Read SecurEnds's full analysis of IGA for core banking fraud prevention →
Core banking access governance: what breaks before fraud starts?
Explore further
07/06/2026 9:49 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: IGA for core banking fraud prevention: where access fails
