Global Bank Identity Hub

A global bank does not have one identity problem — it has one per region, per acquisition, and per line of business. Retail, corporate, treasury, and wealth divisions each arrived with their own directories, their own login screens, and their own idea of what a “user” was. The bank needed a single identity hub that could present a coherent front to employees and applications without forcing fifteen jurisdictions onto one directory.

The challenge

Years of growth had left the bank with a sprawl of authentication surfaces. Some divisions ran on Microsoft Entra ID, others on Google Workspace, and several legacy units maintained standalone account stores. Every new internal application meant another integration, another credential set, and another audit gap. Regional compliance teams refused to surrender their directories as systems of record, and rightly so — local regulation required them to stay authoritative.

The mandate was federation without consolidation: one hub, many sources of truth.

What Veripass deployed

Veripass became the control plane that sits above the existing directories rather than replacing them. Each region was modeled as an isolated organization tenant, so members, policies, and audit history for one jurisdiction never leaked into another. Applications were registered once against the platform and then granted only to the tenants entitled to use them.

External identity providers stayed exactly where they were. Veripass federated with Entra ID and Google Workspace over OIDC, so employees continued to authenticate against their home directory. SCIM handled the lifecycle — accounts provisioned, updated, and deprovisioned upstream flowed automatically into the hub. SAML covered the older relying parties that could not speak OIDC, and API keys carried the machine-to-machine traffic between internal services so no automated job had to borrow a human session.

Authorization moved from per-app role hard-coding to a composable model built from claims, capabilities, roles, and access profiles. Context-aware policy then layered risk on top: a session from an unrecognized context triggered step-up MFA over email or phone TOTP, and the most sensitive treasury operations could demand biometric verification.

• Multi-tenant organization federation, one tenant per region
• Entra ID and Google Workspace federation over OIDC
• SCIM provisioning with SAML for legacy relying parties
• RBAC through claims, capabilities, roles, and access profiles
• Context-aware, policy-based access with adaptive step-up MFA
• Immutable audit trails scoped per tenant

Outcome

The bank retired roughly forty standalone login surfaces in favor of one hub. New internal applications now onboard in days rather than quarters, because federation and provisioning are solved once at the platform layer. Regional directories remained authoritative, so no compliance team had to give up its system of record.

Most importantly, every authentication and authorization decision now lands in an immutable, tenant-scoped audit trail. When a regulator asks who accessed what, under which policy, and why a step-up was demanded, the answer is a query rather than a forensic project. The federation model holds the same whether a given region runs in the cloud, on-premise, or hybrid — only the deployment surface changes.