Identity and Access Management in Banking: Three Gaps Between the Controls

Most banks have the access controls their auditors expect, and the risk in identity and access management in banking sits in the gaps between those controls. Three gaps come up repeatedly: certifications that close without access being removed, customer and workforce identity run as separate systems, and vendor access that outlives its contract.

Key takeaways

• A completed access certification shows that a review happened, not that denied access was removed.
• Segregation-of-duties conflicts are easiest to stop when access is requested, not at the quarterly review.
• Open banking creates third-party identities that sit between a bank’s customer identity and workforce identity systems.
• Verizon’s 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled from 15% to 30% across all industries.
• Vendor access needs a named owner, a default end date and evidence of removal.

What is identity and access management in banking?

Identity and access management in banking is the set of controls that decide who can reach which systems and data, how that access is approved, how it is reviewed, and how it is removed. It covers employees, contractors, vendors, partners and customers. Frameworks such as SOX and PCI DSS are among those that make access evidence matter, because a bank has to be able to show its access decisions as well as make them.

The discipline that ties these decisions together is identity governance and administration. The definition is simple, and the failures happen where its pieces meet: approval and removal, customer and workforce, contract and access.

Why do access certifications pass audits and still miss risk?

An access certification can close on schedule and still carry the conflict an auditor is looking for, because completion is measured and removal isn’t. Many programs track the share of reviews completed by the deadline, and that figure can reach 100% while denied entitlements remain in place. A bank can post a perfect completion rate while the same segregation-of-duties conflict survives cycle after cycle.

How does a reviewer end up approving a conflict?

Reviewers get hundreds of entitlements and an afternoon to work through them, which makes approving faster than understanding. A line manager looking at a row that shows a system code and a role name has to decide in seconds whether someone on their team still needs it. In that setting, rubber-stamping is a reasonable response to how the task is built.

The harder problem is that the conflict is often a combination of permissions, not one role. Each entitlement looks routine on its own row, and the risk only appears when two of them sit on the same person.

What does that look like in a bank?

Two illustrative examples show the pattern. They’re examples, not data.

• The loan officer: A loan officer holds the entitlement to initiate wire transfers and, through a second role picked up while covering for a colleague, can also approve them. Each entitlement passes review on its own line, and the officer can now approve their own wire.
• The trader: A trader can book a position in the trading system and sign off on it in the middle-office tool. Both permissions fit the job title, so neither raises a flag, and the separation between execution and approval no longer exists.

What do auditors look for?

At publicly traded banks, SOX auditors typically look for evidence that access marked as denied was actually removed, and an approved certification doesn’t show that on its own. A reviewer’s decision records intent, while the removal itself, in the directory, the core banking platform and the trading system, is the evidence.

What does good look like for certifications?

A certification program built around removal rather than completion has four features:

1. Conflicts are checked when access is requested as well as when it’s reviewed, so a conflict is stopped before it reaches the quarterly queue.
2. Reviewers see a plain-language description of each entitlement, not a system code.
3. Removal is tracked to completion and evidenced, so every denied item has a record showing it’s gone.
4. Exceptions expire, so a justified conflict doesn’t quietly become a permanent one.

Teams building this into a wider access governance program should measure it by whether denied items are actually gone, since the completion rate only shows that the review took place.

Why does open banking expose the gap between customer and workforce identity?

Open banking creates identities that neither the customer identity system nor the workforce identity system was built to govern. Banks have typically run these as two separate systems, each with a clear purpose.

Workforce identity covers employees and contractors. It’s often owned by IT or security and built around joiners, movers, leavers and access reviews. Customer identity is often owned by digital banking or product teams and built around sign-in, consent and fraud signals at consumer scale.

The separation worked while the two populations rarely met. Open banking changed that by putting third-party fintechs and API partners between them, since customers can permit those third parties to reach their account data and, in some markets, to initiate payments through the bank’s APIs.

Where does the third party sit?

Consider a fintech that acts for a customer in one moment and behaves like an internal system in the next. For example, when it calls an API on a customer’s behalf, it carries customer-granted consent and looks like a customer-side identity. When its engineers need developer portal accounts, sandbox access or support channels, or its service authenticates with credentials the way an internal application does, it looks like a workforce-side identity.

Neither system treats it as fully its own, and each team can reasonably assume the other has it covered.

Juniper Research projects that global open banking API calls will grow from 137 billion in 2025 to 722 billion in 2029, an increase of 427%. The forecast covers 61 countries rather than the US alone, but it shows the direction, because each of those calls comes from a third-party identity that a bank needs to be able to account for.

What question exposes the gap?

The test is one question: who owns this identity, and whose policy governs its access? If the answer for a given partner is the digital team for sign-in, the security team for the developer portal and the partner agreement for everything else, then nobody owns the lifecycle, and nobody is responsible for finding every place the partner can still get in once the relationship ends.

What does good look like for partner identities?

Good looks like one named owner and one policy for third-party and partner identities, whichever system they enter through. That includes a lifecycle covering onboarding, change and removal, and an audit trail showing who approved what and when. Whether a bank reaches that state through one platform or by tightening the handoffs between two, a question about a specific partner should have a single, documented answer.

How does vendor access outlive the contract?

Vendor access outlives the contract because the end date lives in a contract record and the access lives in other systems. Procurement owns the granting side, since a signed agreement triggers requests for accounts, VPN profiles and application roles. Nobody owns the revoking side, because the contract management system that knows the end date doesn’t talk to the directory, the applications or the vendor portals that hold the access.

An illustrative case shows the result. A vendor that supported a payments migration finishes in March, the contract closes in the procurement system, and the vendor’s service account is still working in September because no process connected the two events.

What does the evidence show?

The available evidence measures third-party breaches broadly rather than lingering accounts specifically, but it shows how much of a bank’s exposure sits with vendors. SecurityScorecard’s December 2024 threat intelligence report analyzed the 100 largest US banks by market capitalization and found that 97% experienced a third-party breach, even though only 6% of their vendors were compromised. The same report found that 97% also experienced fourth-party breaches, traced to about 2% of vendors.

Verizon’s 2025 Data Breach Investigations Report, which analyzed 12,195 confirmed breaches between November 2023 and October 2024, found that third-party involvement in breaches doubled from 15% to 30%. That figure is global and covers all industries, so it isn’t specific to banking. Taken together, the two reports suggest that a small share of vendors can expose a large share of banks, and Verizon’s data shows vendor involvement in breaches rising.

What does good look like for vendor access?

Vendor access that ends on schedule has four features:

1. A named internal owner accountable for removing each vendor’s access.
2. Access that expires by default and is renewed on purpose, with the end date enforced in the systems that grant access rather than only recorded in the contract.
3. A record of what the vendor accessed during the engagement.
4. Evidence that removal happened, not only a deactivation date.

Ask the vendor how it governs its own subcontractors’ access, since a bank’s exposure often extends beyond its direct vendors.

How can a bank test its own process?

A bank can test its process with seven questions, each of which should be answered with evidence rather than a policy document. The first two cover certification and identity ownership, and the last five form a filter to apply before a vendor’s access is renewed.

A red flag in any row means the control can’t yet be shown to work, whether it exists only on paper or is missing altogether, and all three gaps in this article sit there.

How OpenIAM approaches these gaps

OpenIAM addresses these gaps with governance controls that coexist with the access models a bank already runs. Its policy-based access control engine works alongside existing role-based access control, so it’s additive rather than a forklift replacement, and a translation tool converts roles into policies. A visual, simulated rule builder handles segregation-of-duties rules, with functional packs for finance and SOX, HR, IT privileged access and procurement. A review campaign can be triggered when a violation is found, and exceptions expire automatically.

Access reviews include an AI assistant for reviewers, detection of rubber-stamp approvals and plain-English entitlement descriptions, and an audit-ready decision log records each access decision. For contractors and external identities, OpenIAM provides a named internal sponsor, scoped permissions and time-bound access with a hard expiry, and extensions need explicit re-approval. One lifecycle model covers employees, contractors, partners and AI agents. How a bank divides ownership between customer and workforce identity remains an architecture decision for the bank itself.

Next step: See how OpenIAM supports banks on these controls

The Financial Services page covers how OpenIAM supports financial institutions on the controls described above, for teams ready to move from testing their process to evaluating a platform.

Frequently asked questions

Q1. What is identity and access management in banking?
A: Identity and access management in banking is the set of controls that decide who can reach which systems and data at a bank, how that access is approved, how it is reviewed and how it is removed. It covers employees, contractors, vendors, partners and customers, and it produces the access evidence that frameworks such as SOX and PCI DSS make important.

Q2. How can a completed access certification still miss risk?
A: A certification can close on schedule while denied access stays in place, because many programs track how many reviews finished rather than whether removals happened. Reviewers also face long queues of entitlements, so approving is faster than understanding, and conflicts that arise from a combination of permissions slip through. Evidence of removal is the test that matters.

Q3. What is segregation of duties in banking, and why does it matter for SOX?
A: Segregation of duties means no single person holds permissions that let them both complete and approve the same sensitive action, such as initiating and approving a wire transfer or booking and signing off on a trade. It matters for publicly traded banks under SOX because auditors testing access controls typically look for conflicts of this kind and for evidence that denied access was removed.

Q4. How should banks manage third-party and vendor access?
A: Banks should give each vendor’s access a named internal owner, a default end date and a record of what the vendor accessed. Access should expire unless it’s renewed on purpose, and removal should be evidenced rather than recorded only as a deactivation date. Banks should also ask vendors how they govern access granted to their own subcontractors.

Q5. How does open banking change identity governance?
A: Open banking puts third-party fintechs and API partners between a bank’s customer identity system and its workforce identity system, and neither was built to govern an identity that lives in both. Identity governance has to answer who owns each partner identity and whose policy governs its access. Juniper Research projects global open banking API calls will reach 722 billion in 2029.