Banking authorization drift: are your controls keeping up?

TL;DR: Fragmented authorization in banking causes services to enforce approvals, thresholds, and audit evidence differently, weakening Zero Trust and complicating PCI DSS 4.0 and supervisory scrutiny, according to Cerbos. When policy lives in code instead of a single runtime layer, access review and incident reconstruction become slower, less reliable, and harder to prove.

NHIMG editorial — based on content published by Cerbos: authorization drift, Zero Trust, and permission management in banking

By the numbers:

• Finance accounts for 27% of all data breaches globally, with an average incident cost of $5.9 million.
• 41.8% of those breaches originated through third-party vendors.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities - 46% confirmed, 26% suspected.

Questions worth separating out

Q: How should banking teams implement authorization without embedding rules in every service?

A: They should move approval thresholds, access conditions, and resource rules into a shared runtime policy layer.

Q: Why does embedded authorization weaken Zero Trust in banking platforms?

A: Zero Trust depends on every request being evaluated against explicit policy at runtime.

Q: What breaks when authorization decisions are not versioned and logged?

A: Auditors and regulators cannot easily see what control was active at a specific time, so teams must reconstruct the answer from deployment records and code history.

Practitioner guidance

• Centralise authorization into a runtime policy layer Move permission decisions out of individual services so approvals, thresholds, and resource checks are evaluated consistently at request time.
• Version every policy change and retain decision traces Store the approved policy version, the identity, the action, the resource, and the evaluation outcome so auditors can reconstruct control state without relying on commit history.
• Treat service accounts as governed identities Inventory machine identities that can initiate payments, read customer records, or call downstream APIs, then scope each one to the minimum action set and context needed.

What's in the full article

Cerbos's full article covers the operational detail this post intentionally leaves for the source:

• A deeper breakdown of how fragmented approval logic changes release velocity across multiple banking services
• The compliance implications of PCI DSS 4.0 and ECB supervisory expectations for control evidence
• A practical architectural direction for separating policy from application code in regulated payment flows
• The article's own framing of how AI-driven execution changes the scope of permission management in banks

👉 Read Cerbos's analysis of authorization drift and Zero Trust in banking →

Banking authorization drift: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →