Payments System Architecture

Nordea is building a new payments platform from scratch for Large Corporates & Institutions and upper Business Banking.

The experience serves:

• 16K customers
• 160K accounts
• Across all Nordic markets

The brief was open: modernise the payments experience on a new platform.

That openness was both an opportunity and a challenge. The existing landscape was genuinely messy with fragmented flows, varied permission structures, deeply different customer needs, and dependencies that stretched across systems and markets.

Early in the project, I led a combination of research and system analysis to understand what was actually going wrong. User interviews, journey mapping, and system analysis revealed a common thread: the platform asked users to do something they fundamentally shouldn't have to: choose among 41 payment types before they'd even started to make a payment.

Most users didn't know which payment type was correct. They'd guess, hit errors, and either abandon the flow or call support. The issue wasn't a confusing UI, but it was that the system was structured around its own internal logic, not how people actually think about sending money.

This insight made me reframe the entire direction. Rather than improving navigation between 41 options, the question became: what if users never had to choose at all?

Understanding the problem deeply

I combined user research like deep interviews, moderated and unmoderated usability testing with detailed journey mapping across different customer types, markets, and permission scenarios. At the same time, I ran a system analysis to understand the technical constraints and dependencies involved.

This combination was deliberate. The problem lived at the intersection of user behaviour and system architecture, so I needed a clear picture of both before proposing anything.

Leading alignment across the organisation

Defining a new direction for payments across 4 markets isn't something you do in isolation. I led over 30 workshops and alignment sessions with product owners, engineers, system architects, and domain experts in order to build shared understanding, surface hidden constraints, and gradually align stakeholders on a common direction.

This work replaced fragmented decision-making with a more unified approach and enabled the organisation to commit to a system-level redesign rather than incremental improvements.

I drove the narrative, pushed back when technical constraints were used as a reason not to improve the experience, and helped the team distinguish between real limitations and assumed ones.

The proposal initially faced resistance, particularly from teams invested in existing payment structures.

I used research, system insights, and concrete scenarios to reframe the problem, helping stakeholders move from optimising individual flows to rethinking the underlying system.

Mapping permissions as a system

Permissions were one of the most complex parts of the problem. Some users can create payments from scratch; others can only work from templates. And permissions didn't just vary by user, they varied by account. A single user could have full rights on some accounts and limited access on others, sometimes across 300+ accounts simultaneously.

I mapped the full range of scenarios and used that to define how the system should behave - adapting to each user's actual access level, preventing invalid actions, and keeping the experience predictable throughout.

Validating scalability with architects

Before committing to a direction, I worked closely with technical architects to validate that the approach could scale across all 41 existing payment types in 4 markets, future types coming in with EU legislation, varying market rules, and evolving permission structures.

This work also influenced technical direction, ensuring that scalability was treated as a core design requirement rather than something to be solved later.

Scalability was a design constraint from day one, not an afterthought.

The central design decision was a fundamental reframe: instead of making it easier to navigate 41 payment types, we removed the choice entirely.

The problem was the complex structure of the system itself. I focused on embedding that complexity into the system, so users never have to encounter it.

This shift influenced both product direction and system architecture.

A dynamic flow that adapts to the user

The solution - a single, unified payment flow where the system determines the payment type rather than the user - came from months of research, system analysis, and pushing the organisation toward a direction that required rethinking some deeply held assumptions about how payments should work.

My role was to define not just what the solution looked like, but what problem it was actually solving. That meant steering the team away from optimising the existing structure and making the case for a more fundamental change: one that touched system architecture, not just UI.

Once the direction was set, I worked closely with technical architects to define and validate the underlying logic, making sure the approach could scale across 41 payment types, varying permission structures, and multiple markets without needing to be rebuilt every time something new was added.

I also established reusable interaction patterns that allow teams to introduce new payment types without redesigning the flow, supporting long-term scalability across the platform.

I made the key calls on where to draw the line between simplicity and completeness. Compliance required fields that almost no one would ever use. Rather than letting those edge cases compromise the core experience, I introduced progressive disclosure as the governing principle in order to keep the flow clean for the vast majority of users while preserving everything that had to be there.

Before launch, I led multiple rounds of usability testing to validate both that the flow worked and - more importantly - that users trusted it, especially those transitioning from the old platform. That distinction mattered because a flow can be technically correct and still feel wrong if users don't believe the system is doing the right thing.

← →

Transition period

Both platforms coexisted during rollout. I identified early that making the new experience too different, too quickly, would create confusion for users operating across both systems in parallel.

I pushed for a progressive approach so that familiar patterns were preserved where needed, improvements introduced gradually, and users could transition without having to relearn core interactions.

Compliance vs. usability

Some payment fields were rarely used but couldn't be removed for regulatory reasons. Exposing them to everyone would hurt usability; hiding them entirely would break compliance.

Progressive disclosure kept everything accessible while surfacing complexity only when genuinely needed.

Data-driven prioritisation

Some payment types that formally existed in the system were almost never used in practice as users had found workarounds. Removing them wasn't an option, but usage data gave us a defensible way to deprioritise them within the new flow without making it a purely subjective design call.