Forty regulated questions, one journey people can finish.
A savings account cannot be opened until a regulator's full data set has been collected and verified. I turned that into an eight-stage journey designed to be completed in one sitting.
A savings account cannot be opened until a regulator's full data set has been collected and verified. I turned that into an eight-stage journey designed to be completed in one sitting.
When I joined, 3 months in, compliance had gathered every regulatory requirement and engineering was waiting. There were no flows, no components and no design system. I designed the journey end to end, from the first screen a customer sees through to a funded account, including every regulatory branch and every point where something could go wrong.
Monument Technology licenses its savings onboarding to banking partners rather than only running its own. Every decision I made fed directly into what the company sells.
Ecology Building Society and Castle Trust Bank would eventually put their name on whatever I built, which meant the journey had to hold up under two different brands without being rebuilt for either.
Before an account can be funded, a provider has to collect and verify identity, address, nationality, National Insurance number, tax residency, US person status, source of funds, employment and income band. That is roughly forty data points, requested from someone with no money in the account and no reason yet to trust the brand.
A usability-testing platform was not available during the project, so I used the strongest evidence sources accessible to the team.
How other UK providers handle the same mandatory data set: where they explain, where they branch, and what they do when a step fails.
Dedicated channels for web and app, plus a weekly clinic. This is where the edge cases surfaced: which lookups fail, which verifications time out.
Working through the actual regulatory requirement rather than treating the first description of it as fixed.
Explain before asking. Name the cost upfront. One decision at a time. Never dead end anyone.
Difficulty had to increase only after someone had decided they wanted the product, so the journey opens on the proposition rather than a sign up wall. Rate and protection detail is reachable before any account exists, and the privacy content sits ahead of the point where personal data is first requested.
Two screens sit deliberately just before registration: one naming the time commitment, one explaining what the data will be used for. Both answer objections that otherwise surface halfway through, at the point where the cost of leaving feels lower than the cost of continuing.
The brief was clear: design the end-to-end journey within a fixed regulatory data requirement. Anti money laundering and tax rules decide what has to be collected, so no question could be cut. Everything else, the order, the wording, and what happens when a step fails, was mine to design from nothing. Every screen below carries its stage number.
Registration opens with decisions about the product rather than the person: individual or joint, how much to deposit, where interest is paid, and which account will fund it. Starting here means the first questions are ones the customer already wants to answer, and the terms are agreed while intent is highest.
With the account itself decided, the next stage turns to the person. Name, mobile number, and PIN come first, so customers make meaningful progress before reaching higher-friction questions. Validation sits beside the field that failed, so a mistyped number is corrected in place rather than reported on submit.
From here every required question got its own screen instead of being bundled into a long form, so each one stayed easy to think about. Date of birth validates in place, and nationality carries its own error state, so the message and the fix appear together rather than the message being stranded at the top of a long scrolling list.
Source of funds and National Insurance number are unavoidable under anti money laundering and tax reporting rules, and they are the two questions people are least willing to answer. Both rely on the explanation placed earlier in the flow rather than a link to terms at the point of asking, and both sit after product setup, when the customer has already decided they want the account.
Tax residency runs to thirteen screens under CRS, and US person status adds four more under FATCA. Someone tax resident in more than one country follows a materially different path from a straightforward UK only resident. The design problem is ordering. Route too late and the majority answer questions irrelevant to them. Route badly and a minority are missed, which is a compliance failure rather than a usability one.
I wanted the tax routing question early so most people could skip it, but the section that actually rules someone in or out runs thirteen screens deep, with four more for FATCA. Compliance needed it to catch anyone tax resident in more than one country, so nothing could be cut.
I reviewed the requirement with the product manager and compliance team, identifying a route that preserved reporting requirements while shortening the path for most customers.
They are the states reached when a lookup fails or a code never arrives, and they are the screens that decide whether an account is opened at all.
Postcode lookup is fast for the majority and fails predictably for new build properties, BFPO addresses and recent movers. A failed lookup is not an error the customer can fix by retrying, so manual entry is a first class path, surfaced at the moment lookup fails rather than buried in help. Without it, a small group of customers is permanently blocked from opening an account through no fault of their own.
Mobile verification is the step customers stall on most, for reasons outside their control: the message is slow, the number was mistyped, the handset is elsewhere. Three distinct failure states cover expired, incorrect and undelivered codes, each with its own recovery action rather than a single generic error.
The last screens before submission bring everything back together, once every answer is already in place, so agreeing to them is a formality rather than a surprise. FSCS protection sits in the flow rather than the footer. For a savings product, is my money safe is the central question, and this is the moment it gets asked. The review step shows every answer back in one editable place, which also lets customers correct anything the branching got wrong.
With the account approved, the final stage sets up how the customer will actually use it. The native permission prompt can only be shown once, and a reflexive dismissal is effectively permanent, so biometrics and notifications are primed on a designed screen before the system dialog fires. Password rules validate live, and marketing preferences are asked once, explicitly, rather than pre ticked.
The full screen set shows the scale of regulated branching, validation, and recovery required. This is what a legally mandated data set looks like once it has been broken into steps a customer can actually complete.
The journey was adopted by two banking brands: Ecology Building Society is live in production, and Castle Trust Bank was onboarded onto the same reusable journey. For a business that licenses this experience to partners, that is the product working rather than a prototype.
Post-launch analytics were not available to me, so I have not claimed conversion outcomes I cannot substantiate. The evidence I can stand behind is the launched journey, more than 20 designed recovery states, and a reusable component system that enabled Monument to onboard a second banking partner without rebuilding the experience from scratch.
The screens nobody wants to design are usually the ones that decide whether the whole thing works: the failed lookup, the code that never arrives, the half finished form. They deserve the same care as the primary flow.
Regulation sets the questions but not the framing. Where an explanation sits, and in whose voice, changes whether people finish. Treating the requirement as a starting point rather than a wall is what shortened the tax path.
Designing without a research tool shaped the evidence available to me. Naming that has been more useful in interviews than implying testing that never happened, and it made the working sessions with engineering count for more.