The Financial Platform Builder’s Wish List

When financial institutions approach modernizing their financial platform, the conversation often starts in the wrong place — around new applications. Features. Interfaces.

If you spend time with the teams actually responsible for delivering these platforms — architects, engineers, and implementation leads — the conversation quickly shifts from vision to execution. How do you make different technologies behave consistently? How do you avoid fragile integrations? How do you support multiple teams without duplicating effort?

In this post, we’re sharing a set of requirements or “wish list” that emerged from a recent proof of concept with a client.

At interop.io, we provide the interoperability foundation for teams to create a scalable, bespoke financial platform. Here’s what we learned.

Modern, Distinctive UI (Not a Tabbed Web App)

One of the first challenges that surfaced was the UI.

You can technically connect a set of applications and call it a platform. But if each component still looks and behaves like a separate tool, the experience breaks down immediately. It feels like a collection of apps, not a system.

The expectation was clear: this should not look like a traditional tabbed interface or a generic web wrapper. The platform needed its own identity — something that felt native (not “your grandfather’s application” as one engineer phrased it).

That meant giving engineering teams control over the details that define the experience. Custom headers. Consistent widget borders. The ability to apply theming at a deep level with control over how the platform looks and behaves.

Without that level of customization at the UI level, even well-integrated applications still feel disconnected. See our article, Rise of Desktop Superapps for more on the importance of UI in these implementations.

Zero-Rekeying Experience (Click-to-Sync Workflows)

The second requirement was around workflows — specifically, eliminating the need for users to re-enter the same information across tools.

In practice, this meant simple interactions like clicking on a client or account in one application and having that context immediately available in another.

There was an additional constraint: this functionality needed to be demonstrated live to non-technical stakeholders, and then immediately explained to engineers in terms of how it was implemented.

That gap between demonstration and implementation is where many approaches break down. If a workflow cannot be shown clearly, it is difficult to get buy-in. If it cannot be implemented cleanly, it is difficult to scale.

Enterprise Security & Identity (SSO, Context, and User-Level Configuration)

Security requirements showed up early and influenced almost every design decision.

Single sign-on was expected, but identity also needed to persist across applications and be usable beyond authentication — for example, in telemetry and observability.

There was also a strong expectation that different user groups would have different platform experiences. Not just access control, but actual differences in configuration, layout, and available applications. That required centralized control, where product and engineering teams could tailor experiences at the group or individual level.

Security, in this case, crucial to how the platform operates.

Zero Install (Browser-Based Access Without Deployment Friction)

Another requirement was straightforward but critical: users should not face technical barriers to accessing the platform.

Advisors needed to be able to access the platform from their own devices, in their own environments, without going through a setup process or installing software locally.

That made browser-based access a requirement for this implementation.

This is often underestimated. Distribution is not separate from architecture. If access depends on controlled environments or deployment cycles, adoption can slow down quickly. Providing a browser-based entry point removes that friction, while still supporting broader platform models — including desktop environments — where they are needed.

Application Reuse (Legacy + Web in One Environment)

No platform starts from a clean slate.

In this case, there was a need to support both existing desktop applications and new web applications within the same environment — as part of a unified model for security, context, and interaction.

This requirement alone eliminates many approaches. If a platform cannot accommodate what already exists, it becomes a migration project. And those are significantly harder to deliver.

Engineering Flexibility & Supportability

Another consistent theme was flexibility.

The engineering team needed to build interoperable components, but they did not want to be constrained in how those components were implemented. Different teams, different use cases, and different technologies all needed to coexist.

At the same time, there was a requirement to provide centralized observability and support capabilities. Engineering teams needed visibility into how the system behaves, how applications are used, and how to support users efficiently at scale.

Without a product that can support this (such as io.Insights) even well-designed platforms become limited without the window into user behavior.

Invest in Order to Continuously Build

Platform builders need a foundation that reduces repeated work, avoids fragile integrations, and allows their teams to focus on what differentiates their platform. Our idea that teams need to “buy in order to continuously build” reflects this approach.

This is why we are strong believers in a buy and build approach.

It is not about choosing between building everything internally or buying a complete solution. It is about starting with a foundation that already solves common problems, so engineering teams can spend their time solving new ones.

The Platform Is Never Finished

For platform teams, the work is continuous as new applications are introduced. Workflows evolve. User expectations continue to change.

That wish list – when achieved – is what separates platforms that get delivered from platforms that continue to benefit the end users and the engineering teams at the helm.