A practical solution guide for architects and IAM teams in financial services. Learn how to choose the deployment model that fits today’s constraints while preserving flexibility for scale, customization, and control tomorrow.
How Apple broke "Sign in with Apple" with an unannounced and silent redirect
Identity programs in financial services rarely fail because a team doesn’t understand OAuth, OIDC, SAML, or MFA. They struggle because identity decisions get made at a single point in time, based on current constraints, and then quietly become the thing that slows down the organization later.
Early on, the goal is usually pragmatic and involves getting secure sign-in working, reducing operational burden, and meeting baseline requirements without having to build it yourself. But over time, institutions evolve, teams grow, time-to-market accelerates. And suddenly the identity approach that was “perfect for us” becomes a patchwork of workarounds, vendor tickets, and poor user experiences (not just for end users, but admins too).
The real challenge isn’t picking the “best” identity solution. It’s picking an approach that matches your institution’s operating reality today while keeping a clean path to where you may need to be tomorrow – without forcing a rewrite of every integration along the way.
That’s what “right-sizing” identity means in practice: aligning the identity operating model to your size, complexity, and change velocity, then designing for growth without assuming everyone needs the same destination.
Financial services spans credit unions, regional and national banks, global systemically important banks (G-SIBs), insurers, wealth managers, fintechs, and capital markets firms – all of which operate under different regulatory pressures, risk models, customer expectations, and delivery speeds.
That diversity matters because identity is an operating model choice as much as it is a product choice.
Two institutions can want the same outcomes on paper (MFA, SSO, OIDC, SCIM, step-up auth, auditability) and still need very different architectures based on:
In other words: the first architectural decision isn’t “which platform has the longest checklist?” It’s what level of ownership and accountability makes sense for your institution.
A useful way to simplify the decision is to view identity in two broad approaches:
For smaller teams, managed identity is often the highest-leverage move: fewer moving parts to run, faster time-to-value, and less identity platform engineering required day-to-day.
This aligns well with credit unions, regional banks, and smaller wealth/investment firms that want to ship secure experiences without building a dedicated identity platform team with the org.
The trap to avoid is “managed now means locked forever.” The strongest managed approaches are the ones where you can start simple, then increase control over time without rewriting every integration. That flexibility and modularity matters because identity integrations get sticky fast.
For larger institutions, or smaller ones with unusually strong platform teams, self-hosting becomes compelling when:
Self-hosting is effectively saying: we want to own this system as a critical part of our architecture, and we accept what comes with that: resourcing, security posture, on-call, lifecycle management, and operational maturity.
In practice, institutions take on more identity ownership (i.e. self-hosting) for three reasons: customization, scale, and data residency.
The most common hurdle in identity is not about standards, it’s about user journeys.
The line of business wants:
This is where identity becomes more than security control and part of the business and product. And that’s where limitations hurt most because when identity is not flexible, the business ships workarounds. At that point, the ability to customize is a business requirement.
And the core question becomes: do you want your ability to improve journeys to be constrained by external roadmap timing or by your own priorities and delivery capability?
Scale is tricky in financial services because it doesn’t only mean a high volume of users. It can show up as traffic spikes during a campaign or incident, high-volume API authorization patterns, partner ecosystems that multiply token issuance and validation, region-specific deployments, and demanding availability expectations. When identity goes down, the business goes down too.
Even the definition of scale shifts as institutions modernize and add new channels and workflows.
Managed services can scale impressively until you hit a limit you don’t control such as rate limiting, data residency options, and cost curves that impact your IAM spend.
Taking on more ownership is often about gaining control of the knobs:
Greater ownership lets you decide how you scale, and where your constraints live.
Data residency is a frequent driver in financial services, especially once you operate across jurisdictions or have strict internal policies. When residency requirements get real, architectural flexibility matters.
Taking on more ownership can simplify the story:
When residency is non-negotiable, control becomes valuable.
There’s another reason identity operating models get revisited: cost and pricing control.
Many teams are rethinking how much they want to outsource to SaaS not out of ideology, but because they want clearer unit economics, fewer surprises as usage grows, and stronger negotiating leverage.
This shows up increasingly as a motivation to bring workloads back into environments the institution can govern more directly (including private cloud or “self-managed in our cloud,” not only on-prem).
If you’re debating whether to stay managed or move toward greater ownership, these questions usually surface the truth quickly:
1. Do we have the people to run it well? This is the first filter. Owning identity is an operating commitment, not just a deployment option.
2. Do we want full ownership? Full ownership (e.g., self-managed) can be the right move when you need maximum control over your identity architecture and how it evolves. It puts your team in the driver’s seat to define and operate the security, privacy, and reliability posture directly. Self-hosting is best suited to financial institutions that want that level of control and have the capacity to run it confidently.
3. Are we blocked by roadmap or platform constraints? If “we’re waiting” is a recurring sentence, especially around user journeys, customization pressure is building.
4. Are scale, residency, or topology constraints becoming strategic? When those constraints start shaping product decisions, it’s time to consider increased ownership.
5. Are we trying to control cost curves vs. accepting vendor pricing? If you can’t forecast identity spend confidently as usage grows, you’ll eventually revisit the model.
Right-sizing identity isn’t about pushing everyone toward the same destination. Choosing an operating model that fits your institution today helps you to avoid decisions that create unnecessary rework later.
Some institutions should absolutely start with a managed solution because speed and simplicity matter more than maximum control right now. Others need deeper ownership sooner because customization, residency, scale, or cost predictability is already strategic.
The goal is a clean progression path: identity that fits where you are today, and doesn’t punish you when you grow.
If you want identity that fits today and tomorrow, Ory is designed to meet you where you are. Start with Ory Network (SaaS) to minimize operational overhead and move fast, or choose the Ory Enterprise License (self-hosted) when you need maximum control without taking on the full burden of production hardening and security response yourself.
No matter which path to modern Identity you choose, Ory is here to solve customization, scale, and data residency the way you want it, the where you want it, and the how you want it.
Want to discover which path is right for your institution? Contact us and we’ll help you map the right operating model based on your business needs today and where you’re headed next.
