Designing permissions-driven access for payments

Nordea was building a new banking platform for Large Corporates & Institutions and upper Business Banking, serving 16,000 customers, 160,000 accounts, and multiple markets.

The reality of this environment is genuinely complex. A single user might have full rights on one account, limited rights on another, and no access at all on a third. On top of that, payments were organised across multiple pages and entry points, each tied to different payment types and contexts. Getting access right wasn’t a small design consideration, but it was central to whether the platform would actually work for the people using it.

The platform was being built from scratch, which meant the typical issues hadn’t surfaced yet. I identified early that this needed a clear approach before the platform scaled further.

Each payment type was being introduced with its own entry point and page structure. In isolation, this made sense. But I recognised that at scale, it would become a fragmentation problem — a future where access, navigation, and behaviour diverged across payment types, with no consistent logic holding it together.

I also saw that permissions hadn’t been given the structural attention they needed. They varied by user, by account, and by action, and without a clear model to govern them, the trajectory was predictable: users would end up on pages they couldn’t use, actions would appear that weren’t actually permitted, and flows would fail mid-way through.

The experience wasn’t broken yet. It became clear that the real problem was the absence of a system, and that it needed to be defined before these patterns became embedded in the platform. I made the case for addressing this early, and drove the work forward from there.

Treating permissions as a system, not a collection of edge cases

The first thing I did was map all permissions across roles, actions (create, edit, confirm), and account-level variations. That exercise surfaced 24 distinct permission combinations. I used them as the foundation for the entire solution.

From there, I designed access at three interconnected levels:

• Page visibility — users should only see pages they can actually access, replacing error states with the absence of irrelevant options
• Actions within pages — what a user can do adapts based on their permissions, so there are no dead buttons or blocked interactions
• Entry points into flows — users only see paths they can successfully complete, preventing failures before they start

Challenging the initial direction

The original proposal was to show all pages and handle access through error messages. I saw an opportunity to improve this by defining access earlier in the experience, so users wouldn’t encounter issues after already starting an action.

I reframed the challenge: access should be determined before interaction, not after failure. That shift — from reactive error handling to proactive system behaviour — became the design principle that everything else followed.

Working across the organisation

Because permissions touched so many domains, I knew this couldn’t be solved in isolation. I worked closely with technical architects, backend and frontend engineers, product owners, and access management teams. I also collaborated with related domain teams including Payments Hub and User Administration team.

The goal was to build a model that worked across all payment types and pages, was technically feasible to implement, and could scale as the platform grew. Getting alignment across those groups required being clear about the principle driving the design, and patient in making the case for why a proactive model was worth the investment.

The guiding principle

Access to payments is now determined by who the user is, which account they’re working with, and what actions they’re permitted to take. That logic drives everything: which pages are visible, which actions are available, and which entry points are shown.

This replaced a fragmented, page-based access structure with a unified, permission-driven model.

Pages adapt to each user and account. There’s no more dead-end navigation or permission errors encountered mid-flow. Actions like create, edit, and confirm are shown or hidden dynamically, so users only see what they can actually do. Entry points are tailored to permission level — some users see one option, others see two — preventing failure inside the payment flow itself.

The most meaningful outcome was organisational. The permission model became a shared reference across teams — shifting access decisions from ad-hoc solutions to a consistent framework.