Designing CIAM For Retail Banking: All The Core Journeys You'll Need

The Reality Check

Too often, CIAM journeys are built one channel at a time. Mobile login here, web onboarding there, branch-only password resets. It works at first—until it doesn’t. As each channel evolves, it throws new demands at CIAM. You patch, you duplicate, you tech-debt your way forward. Before long, your identity layer becomes a spaghetti mess.

This article is your escape route. We’re laying out a definitive list of IAM journeys and features that a retail bank CIAM should have to serve any channel, cleanly and consistently.

What CIAM Should Handle (At a Minimum)

Before diving into journeys, let’s anchor ourselves:

• Authentication – Proving who you are

• Authorization – Controlling what you can do

• Onboarding – Creating your digital identity

• Credential Management – Managing secrets and devices

• Profile Management – Keeping your identity up to date

Simple enough. Now let’s get to the good stuff.

Authentication: One Identity, Many Ways to Prove It

Before we talk about journeys, let’s talk about ingredients.

Every authentication journey in a retail bank should be composed using a flexible set of authentication methods. These methods are modular primitives—you don’t build a new journey from scratch for every channel or use case. You combine methods to meet the contextual requirements of security, risk, and user experience.

These will be your reusable authentication methods:

1. Password (Username Optional)

Support traditional password auth. But don’t require a username if you already have unique identifiers like mobile or email. Simpler is smarter.

2. OTP (SMS, Email, TOTP)

• SMS OTP: Standard but prone to SIM swap.

• Email OTP: Good backup, but phishing-prone.

• TOTP: Best for resilience—tie it to your mobile app for a stronger link.

3. Device-Based Authentication

• PKI on registered mobile devicesUse device-stored private keys for asymmetric auth. Great for high-trust flows.

• FIDO2 PasskeysLeverage platform authenticators (Touch ID, Face ID, Windows Hello). Works across web and app.

• Push AuthenticationLet the mobile app approve logins on other channels (e.g., web login approved on phone).

  Pro tip: Use a pull-push hybrid:

  • CIAM can send a push notification to registered mobile app for a push authentication

  • Mobile app can pull from CIAM if there is any pending push authentication

Once your authentication methods are clearly defined, you can start composing authentication journeys tailored to different scenarios. This modular, mix-and-match approach helps you avoid duplicating logic across channels, delivers a consistent user experience, and ensures your CIAM remains flexible and scalable for new device types, regulatory shifts, and emerging threats.

Authorization: It’s Not Just “Logged In” — It’s “Allowed In”

When we talk about identity systems, a common confusion trips up even seasoned developers: OIDC is not authorization.

OIDC—OpenID Connect—is a protocol built on top of OAuth2, and its job is authentication. It helps you answer: “Who is this user?” It’s great for federated login scenarios, like when a third-party app wants to let users log in using your CIAM as the identity provider. But it stops there. It doesn't determine what a user is allowed to do once logged in.

That’s where OAuth 2 comes in. OAuth 2 is the engine behind authorization, and it's the backbone of any scalable, secure, and channel-agnostic CIAM. It lets you issue access tokens and refresh tokens that define exactly what actions a user can perform, and on which resources.

To do this right in a modern retail bank, always lean on the Authorization Code Grant flow. It’s designed for interactive login, and when used with PKCE (Proof Key for Code Exchange), it becomes safe even for public clients like mobile apps or single-page applications. That means you can issue tokens directly to your frontend applications, without exposing client secrets or relying on backend coupling.

Onboarding: Keep It Focused, Not Bloated

In a channel-agnostic CIAM design, digital identity onboarding must serve one purpose and serve it well: to create a verified, deduplicated digital identity—nothing more, nothing less.

It starts with electronic Know Your Customer (eKYC) and ends with basic credential nomination such as setting up the password. This journey collects the identity information necessary to establish a legal and functional identity, such as government ID details, contact information, and biometric verification.

Critically, this process should not be entangled with product onboarding. Creating a user identity is fundamentally different from enrolling someone in a savings account, credit card, or investment product. Merging these flows results in rigid, over-engineered experiences that are difficult to reuse across channels.

By keeping onboarding clean and purpose-specific, you enable CIAM to serve as a stable, centralised identity layer. Channels can then focus on their own UX and product logic without reinventing the identity wheel at every touchpoint.

Credential Management: The Foundation of Secure Identity

Credential management in a CIAM platform is more than just handling forgotten passwords—it’s the security backbone of identity integrity. In a retail banking environment, where trust and regulatory compliance are non-negotiable, these flows must be designed with precision and defense-in-depth.

1. Ditch the Username When You Can

Modern CIAM platforms should treat mobile numbers or email addresses as primary identifiers. If an identifier is globally unique and verified, there's often no need to burden users with creating or remembering a traditional username. This simplifies authentication flows and improves usability without compromising security.

2. Rethink the “Forgot Password” Journey

Password recovery is one of the most targeted and exploited flows. A secure CIAM should treat this journey as a sensitive, pre-authenticated action. Use OTPs, push authentication, or eKYC verification before allowing a password reset. Avoid the use of magic links sent via email—these are convenient but risky. In a banking context, they create poor habits and open the door to phishing threats. Email should never be a path to full account recovery.

3. Changing Passwords: Require Proof, Not Just Memory

Changing a password shouldn’t be as simple as typing in the old one. It should be offered as a post authentication journey and not coupled as an alternative to Forgot Password.

4. Device Change: A High-Risk, High-Control Flow

When a user changes devices—this will mean that the user has to register their new device for PKI establishment or FIDO authentication—the flow becomes a high-stakes journey. Verify identity using strong factors, detect rooted or jailbroken environments and enforce malware checks before provisioning new keys. Device-based credentials are powerful because they’re hard to steal—but that also makes them critical to protect when being replaced.

By treating credential management as a core pillar of your CIAM—rather than a secondary UX concern—you ensure that identity remains both secure and consistent across all channels.

Profile Management: Maintain Trust, Enforce Control

Profile management is the operational heart of any identity system. It ensures that once an identity is established, it can be maintained, updated, and controlled securely—both by the user and by authorized administrators. In a channel-agnostic CIAM platform, profile management must be accessible, auditable, and consistent across web, mobile, and internal channels.

Empowering Users Through Self-Service

Modern customers expect to manage their own information on demand. A CIAM platform should support self-service updates for key attributes such as mobile number, email address, and registered devices. These updates should always be gated by secure authentication and verification steps to prevent unauthorized changes.

A particularly critical but often overlooked aspect of profile management is authorization visibility. Users should be able to view which applications have been granted access to their identity data or tokens. More importantly, they must have the ability to revoke previous authorization at any time. This capability becomes indispensable in Open Banking environments, where consent-based data sharing is regulated and monitored.

Enabling Operational Oversight

Equally important is the administrative control layer, typically accessed by customer support teams, fraud analysts, or compliance officers. The CIAM platform should offer robust tools for authorized personnel to lock or unlock user accounts, review profile information, and revoke credentials when compromise or misuse is suspected.

These administrative capabilities ensure that CIAM isn’t just user-facing—it also supports the institution's operational, legal, and risk management obligations. Profile actions should be fully auditable, role-based, and aligned with data protection regulations.

Transactional Authorization & Signing: Securing Action, Not Just the Login

In a retail banking context, authenticating a user once at login is not enough. High-value or sensitive operations—like money transfers, bill payments, or adding new payees—require additional layers of consent and verification. This is where transactional authorization and transaction signing come into play.

These mechanisms elevate security beyond the basic session, ensuring that each critical transaction is independently approved and verifiable. They help prevent fraud, reinforce trust, support regulatory requirements and enforce non-repudiation.

Transactional Authorization

Transactional authorization is the process of confirming that a user explicitly approves a specific action at the time it occurs. This goes beyond a general login and requires authentication and authorization for a particular transaction.

What makes transactional authorization transactional is the tokenisation of intent. When the user authenticates and authorize a transaction, CIAM should issue a token that is scoped exclusively to that transaction. The token can either carry a transaction hash or the key attributes of the payload.

Transaction Signing

While transactional authorization can involve using any authentication method, transaction signing represents a more advanced and secure variant of this journey. To enable transaction signing, the authentication method must involve a device-based cryptographic signing.

This process ensures non-repudiation: because the bank never possesses the user’s private key, and the transaction is cryptographically bound to the user’s approval on his or her device, the signature serves as strong legal and forensic evidence in case of a dispute.

Single Sign-On (SSO): Seamless Identity Across Channels, Without the Cookie

In a truly omni-channel banking experience, users should be able to move fluidly between channels—whether it's from mobile to web, between web applications, or from one app to another—without being asked to re-authenticate. This is the promise of Single Sign-On (SSO): authenticate once, and access everything securely.

The Common Approach: Cookies and Workarounds

For the longest time, SSO has been implemented using http only sso cookies and browser tricks like hidden iframes, relying on shared domains to propagate authentication across web properties. This approach, while functional, quickly complicates in a modern architecture that includes:

• Native mobile apps

• Micro frontends

• Cross-domain web portals

• App-to-app transitions with no browser context

Even with OAuth 2 driven SSO implementation, cookie dependencies are often still around.

A cleaner solution: One-Time Use Code for Identity Handoff

Rather than relying on SSO cookies , a more robust approach is to leverage the idea behind OAuth 2's Authorization Code flow—but adapt it to the SSO context.

In this solution, the CIAM platform can issues a one-time-use, short-lived identity code when a user is already authenticated in one channel. This code is not part of the traditional OAuth2 authorization request, but conceptually similar: it represents a temporary, transferable proof of identity.

Here’s how it works:

1. A user authenticated in Channel A (e.g., mobile app).

2. Channel A before transiting to Channel B, request CIAM to generate a one-time identity code using the CIAM issued token it is holding.

3. Channel A transitions to Channel B (e.g., web browser or another app) with the one-time identity code.

4. Channel B presents the code to CIAM to re-establish the user’s identity.

This approach enables clean and consistent SSO across platforms—whether it’s app-to-app, app-to-web, or web-to-web—without requiring persistent cookies, browser tricks, or shared domains.

Final Thoughts: Build Once, Apply Everywhere

Channel-agnostic CIAM isn’t a futuristic vision—it’s an operational necessity in modern retail banking. As customers move seamlessly between mobile apps, web platforms, and third-party ecosystems, your identity system must keep up—without sacrificing security, consistency, or user experience.

This article laid out the core journeys and features your CIAM platform should offer, not as isolated use cases, but as composable capabilities. From flexible authentication building blocks to identity handoffs across channels, the goal is clear: Build Once, Apply Everywhere.

By decoupling identity from channels, you're not only reducing duplication and technical debt—you’re empowering your organization to scale faster, respond quicker, and deliver trust at every touchpoint.

Whether it’s onboarding a customer, authorizing a high-value transaction, managing devices, or facilitating app-to-app SSO, a well-architected CIAM platform ensures every channel gets identity right—without reinventing the wheel.