Two questions banks must now answer faster than the directory will let them
Most banks run a layered identity stack: an HR system as the source of truth for employment, an identity directory for who logs in, an identity governance platform for entitlements, and access tables in two hundred or more downstream applications. Each layer was built when “who has access to what” had a short, list-shaped answer.
The regulator's question
"Who can do what, and who approved it?" Defended in audit without three weeks of spreadsheet reconciliation.
The customer's question
"What can I do, now, on this account?" Answered in sub-milliseconds, respecting subsidiary structure, role and thresholds.
The regulator names the duty, not the cadence
Most regulators require these reviews “regularly” or “periodically” without naming an interval. Australia is a useful illustration: the standard leaves the firm to justify the cadence against its own risk assessment.
| Jurisdiction | Instrument | Cadence language |
|---|---|---|
| Australia | APRA CPS 234 (1 July 2019) | controls “commensurate with criticality and sensitivity” |
| Australia | APRA CPS 230 (1 July 2025) | comprehensive op-risk profile review, no fixed access interval |
That looseness is what lets annual, spreadsheet-led attestation just about defend itself in audit, even when the access estate changes daily.
Knowing who has access, before the regulator asks
An access review is a join across three systems the bank already runs: HR for who reports to whom, AD or Entra for which groups they belong to, and the per-application catalogue for what those groups grant. Today that join is rebuilt in a spreadsheet at the end of every cycle. Yearly, because everything about it is manual: producing the report, then walking each manager through every reportee’s entitlements one by one. The data is graph-shaped; the tools are not.
What the graph adds beyond the spreadsheet
With the data held where it belongs, in a graph that mirrors the relationships across HR, AD and the application catalogue, the review becomes a single query rooted at each manager and surfaced through a thin approval UI. Quarterly, monthly, or continuous is no longer a capacity question. A tier-one UK bank moved from annual Excel-based certification to quarterly graph-driven approvals on this pattern.
Two capabilities follow that no spreadsheet can match.
Peer-cohort anomaly detection
Similarity algorithms over the entitlements held by a team flag the employee whose access does not look like their peers'. The question every reviewer wants to ask, and none of them can ask in Excel.
Cycle detection
When AD hierarchies drift, a manager ends up approving a reportee whose own approval chain points back to that manager. A trivial Cypher pattern, catastrophic in spreadsheets.
What to say to a corporate banking customer about access
Open with the login. A treasury manager logs in and expects, in milliseconds, to see which subsidiaries they can act on, what they can read versus edit, what triggers an approval chain, and who the approvers are. Six or more hops, on every login, against a structure that nests as deep as the customer’s group has grown. Legacy platforms either pre-compute and go stale, or compute on demand and go slow.
With the data held where it belongs, in a graph that mirrors the customer’s corporate structure, every login resolves to a single traversal across user, organisation, account, role and threshold. The same query answers “what can I see” and “what needs approval”. Two capabilities follow that the legacy stack cannot deliver.
Sub-millisecond effective access
Even when the customer's group has hundreds of subsidiaries and threshold rules vary by account, the login resolves in a single traversal. No pre-computed cache to go stale, no on-demand join to go slow.
Customer self-administration
The treasury manager onboards their own users, sets roles, and configures approval thresholds without the bank's operations team in the loop. Faster customer onboarding, fewer support tickets, lower cost to serve.
This is the same pattern Google’s Zanzibar built for Drive and YouTube and the open-source community packaged as Relationship-Based Access Control. It is well-trodden ground in the wider industry.