Here’s a scenario that’s common across large financial institutions: an enterprise operates dozens of customer-facing portals. Online banking. Wealth management. Mortgage servicing. Credit cards. Business banking. Insurance. And so on, each acquired, built, or inherited at different points over the last fifteen years.

Every single one has its own identity system.

A separate user store for each portal. Separate credential policies. Separate MFA implementations. Separate session management code written by different teams who may not even work at the company anymore.

If you’re an architect looking at this, you already know the punchline: this is unsustainable. The fundamental issue is that identity has been treated as a feature bundled inside each portal, not as an independent architectural layer. When identity is embedded in a portal vendor’s product, it’s invisible as an architectural concern — no independent SLA, no dedicated compliance scope, no portability. You don’t bundle your message bus into your CRM. You shouldn’t bundle your authentication engine into your portal.

The Hidden Costs of Portal Silos

Security inconsistency. Portal A enforces WebAuthn. Portal B still allows SMS-based MFA. Portal C has a password policy from 2019. An attacker targets the weakest link — and with that many silos, your weakest link is weaker than you think.

Customer friction. A customer with accounts across five portals manages five sets of credentials. No single sign-on. Every portal feels like a different company — because architecturally, it is.

Compliance multiplication. Every silo is another audit surface, another penetration test target, another set of evidence to collect. Your compliance team proves the same controls work slightly differently across every system instead of proving them once.

Concentration risk. It’s tempting to think many portals equals distributed risk. The opposite is true. Each portal independently couples authentication availability to portal availability, creates a separate compliance attestation gap, and locks customer credentials to a vendor relationship. You have the same structural vulnerability repeated everywhere, and no single system owns the full picture.

Why Now

CFPB Section 1033 compliance starts April 2026 for tier-1 institutions. Consumer-permissioned financial data sharing via FDX APIs, built on FAPI 2.0 security profiles. You cannot implement FDX consent flows across dozens of disconnected identity systems without multiplying cost and audit surface.

AI agents need identity. I wrote about non-human identities previously. Siloed identity systems have no framework for agent delegation, scoped access, or cross-portal trust. A centralized identity platform does.

FAPI 2.0 is finalized. As of 2024, there’s a certified, proven security profile for financial-grade authentication. The “build vs. standard” debate is over.

The Architecture: Hub-and-Spoke

A central Identity Broker acts as the single OIDC Provider for every portal. Each portal becomes a Relying Party. The IdP answers one question: is this person who they claim to be? Everything after that — authorization, business rules, access control — is the portal’s problem.

Authentication consolidates centrally. Authorization stays distributed. A common anti-pattern is pushing authorization logic into the central IdP. This creates a god-service that knows every portal’s business rules, couples portal deployments to IdP changes, and turns your identity platform into a bottleneck for every feature release. Don’t do this.

This is separation of concerns applied at the vendor boundary. A portal vendor’s job is to deliver a customer experience. An identity vendor’s job is to authenticate. When one vendor does both, you lose the ability to independently govern, audit, or replace either concern.

The architectural payoff is portal portability. Once identity is an independent layer, the portal becomes a stateless consumer of authentication. You can replace, upgrade, or sunset any portal without triggering a credential migration.

At this scale, Back-Channel Logout (server-to-server, not browser iframes) is the only viable session termination approach. Token Exchange (RFC 8693) handles cross-portal delegation — always use delegation mode with act claims over impersonation to preserve the full audit trail.

Three Classes of Identity

You’re not just consolidating human logins. You’re building an identity platform that serves three fundamentally different actor types.

Human customers authenticate via Authorization Code with PKCE, sender-constrained tokens (DPoP or MTLS) per FAPI 2.0, and phishing-resistant MFA (FIDO2/WebAuthn) for anything touching financial data. No SMS fallback for high-value operations.

Services and APIs use Client Credentials with mutual TLS. Short-lived access tokens (5-15 minutes), no refresh tokens. For cloud-native services, workload identity federation (AWS IAM Role, GCP Service Account, Azure Managed Identity) eliminates stored secrets entirely. SPIFFE/SPIRE provides the same capability across heterogeneous infrastructure. An emerging pattern: MCP (Model Context Protocol) servers, which expose internal tools and data as structured capabilities for AI models. Each MCP server is a service identity that needs the same FAPI-grade token binding as any direct API — treat them as first-class machine identities, not informal integrations with static API keys.

Non-human identities outnumber human identities by 40:1 to 80:1 in modern enterprises. When you consolidate dozens of portals, expect to inherit hundreds of undocumented service accounts, API keys, and OAuth clients. Your NHI inventory will be larger than you think.

AI agents use delegated user identity: the agent acts on behalf of a human with explicitly scoped, constrained tokens carrying both user identity (sub) and agent identity (act claim). Agent-as-principal — where an agent has its own independent identity — is not ready for production financial services. The IETF drafts and OIDC-A proposals are active but unratified, and no regulatory framework addresses autonomous agent access to financial data yet.

CIBA (RFC 9541) as agentic proof of concept. CIBA decouples the authentication channel from the consumption channel — an agent’s desktop initiates an auth request, the customer authenticates on their own device. That’s the exact pattern customer-facing AI agents will need. Any institution implementing CIBA for call center workflows is building the infrastructure pattern that agentic identity will require.

FAPI 2.0 and FDX Consent

FAPI 2.0 is built on an explicit attacker model — network attackers who can intercept, modify, and inject messages. The key mandatory requirements: Pushed Authorization Requests (PAR) to prevent request parameter tampering, sender-constrained tokens (DPoP or MTLS) so stolen tokens are useless without the private key, PKCE with S256 on all authorization code flows, and Rich Authorization Requests (RAR) for fine-grained consent beyond flat scopes.

RAR is what makes FDX consent work. Instead of read:accounts, the consent says: “access checking account ending in 4521, transaction history for last 90 days, until December 31, 2026.” The FDX consent lifecycle — creation via PAR with RAR, management via Grant Management API, revocation, and time-bounded expiry — maps cleanly onto these OIDC/FAPI primitives.

There’s a longevity argument beyond compliance. FAPI 2.0, FDX, and emerging agentic identity standards all assume a dedicated, standards-compliant identity layer exists independently of the applications consuming it. A portal vendor’s bundled IdP will never be at the frontier of these standards — it’s not their core product. Choosing a dedicated identity vendor that’s FAPI-certified and participating in agentic identity standards work is an architectural bet on longevity.

The Build vs Buy Decision

For a financial institution consolidating dozens of portals, self-managing the identity platform is almost certainly the wrong choice. Self-managed runs $1.5M-$3.5M/year (8-14 FTEs, HSM infrastructure, multi-region deployment, compliance audits, 24/7 on-call). A managed SP runs $500K-$2M/year. Typical savings: 30-50% in direct costs, plus recaptured engineering capacity.

A managed SP transfers operational burden. It does not transfer regulatory accountability. OCC Bulletin 2023-17 requires due diligence, ongoing monitoring, contingency planning, and board-level oversight.

There’s a third-party risk dimension that strengthens the case for separation. When identity is bundled inside a portal vendor, you cannot produce an independent control attestation for authentication — it’s buried in a broader SOC 2 scope that was never designed to answer identity-specific questions. A dedicated identity vendor gives you a clean, independently scoped control environment that maps directly to what examiners expect.

As of early 2026, only Auth0/Okta (Highly Regulated Identity) and Ping Identity have FAPI 2.0 certification as full CIAM platforms. That’s a short list, which creates lock-in risk. Mitigate architecturally: standard OIDC protocols only (no vendor SDKs), configuration as code, contractual data export rights, 6-12 month exit runway, and a thin identity abstraction layer in your application code. Teams skip the abstraction layer because “we’ll never switch.” They always regret it — not because they switch vendors, but because the vendor changes their API.

The Migration: Strangler Fig

Phased, with dual-stack coexistence at every step. The new identity layer is introduced alongside the existing ones, takes on new traffic progressively, and the old bundled implementations are retired one by one.

Foundation (months 1-3) — deploy the OP, configure FAPI 2.0, set up FDX consent framework, build integration reference for portal teams. Pilot (months 3-5) — migrate 2-3 lowest-risk portals with shadow authentication running in parallel. Wave migration (months 5-12) — portals in waves of 3-4, prioritized by risk, complexity, and user overlap. NHI migration (months 8-14) — inventory all API clients (expect 3-5x more than documented), migrate to central OP. Decommission (months 12-18) — remove legacy identity systems, consolidate and de-duplicate user stores.

One timing constraint: the cost of deferral compounds at the procurement layer. Every portal contract that renews without identity decoupling is contractually locked technical debt. Align migration sequencing to contract renewal cycles.

And don’t underestimate user store merging. Two portals may have the same customer with different email addresses and conflicting profile data. Account merging logic deserves its own workstream — not a cleanup task at the end.

What I’d Do

Start with the reference architecture layer model. Identity is the foundation layer. Everything else depends on getting it right first.

Pick the managed SP early. Evaluate on multi-tenant configuration, FDX consent flow, white-label branding, and contract terms. Don’t let vendor selection drift.

Inventory your NHIs immediately. Every organization that does this finds more than expected.

Don’t wait for agent identity standards to mature. Use delegated user identity now. It works within existing OIDC/FAPI frameworks and is the only model regulators will accept today.

Build the abstraction layer from day one. Your vendor will change their product. You want that change absorbed at the edge, not propagated through every portal.

Every identity silo is a liability. One well-architected identity platform is a competitive advantage. The standards exist. The vendors are certified. The migration path is well-understood. The only question is when you start.