A regulated onboarding built for waiting, failure and recovery

The screen count hid a state-ownership problem.

The delivered flow spanned dozens of screens and states across account setup, personal and tax data, consent, identity, trusted-device setup, address evidence, declarations and provisioning. Its complexity came from dependencies that could wait, reject input or stop the automated path.

A reconstructed map of a regulated mobile onboarding, showing the connected route, external dependencies, retry paths and support boundaries. — Public-safe reconstruction of the delivered flow structure. Real interfaces and implementation details are removed. View map full size

Connected routeCore setup and provisioning stayed legible as one journey.
Dependency ownershipWaiting states named which part of the system still had work to do.
Recovery boundaryThe flow separated recoverable input from manual assistance.

External verification needed an explicit handoff.

The external identity step introduced preparation, handoff, waiting, returned failure and terminal escalation states. Generic loading or error treatment would not explain who owned the delay or what the customer could do next.

Constraint: The dependency could not always provide an immediate answer.
Insufficient: A generic loader or retry would not explain ownership, status or the next valid action.
Decision: I separated preparation, waiting and action states, each with explicit ownership.
Consequence: The flow made the next available action clear without pretending the delay had disappeared.

IdentityChecking

Getting things ready

The verification provider is preparing the identity check. This may take a moment.

•••

Provider response pendingThe journey continues when the external check responds.

Preparing verification

A simple rule set kept recovery consistent.

Across the critical interruptions, I designed three recurring patterns. The same structure guided copy, controls and handoff behavior across the journey.

Wait
Dependency still working

Message
Explain the delay and its owner.
Control
Do not present an action that cannot succeed yet.
Next
Continue after the dependency responds.
Retry
Input rejected but recoverable

Message
Explain what needs replacement and what counts as valid.
Control
Reopen the failed task with replacement controls.
Next
Validate the new input and return to the route.
Escalate
Automated path exhausted

Message
State the boundary without ambiguity.
Control
Stop presenting retry as a viable option.
Next
Route to support or manual review.

The state model remained useful after delivery.

I prepared the onboarding architecture and recovery logic as a reviewable development handoff. The structure remained stable through later maintenance and became the starting point for an organization-verification variant.

End-to-end ownership: Individual onboarding from account setup through provisioning.
Reviewable contract: Dependencies, waiting, rejection, retry and support boundaries mapped together.
Durable structure: Later verification work reused the same state model instead of starting from an empty flow.

A regulated onboarding built for waiting, failure and recovery.

The screen count hid a state-ownership problem.

External verification needed an explicit handoff.

Getting things ready

A simple rule set kept recovery consistent.

Wait

Retry

Escalate

The state model remained useful after delivery.

Need a complex financial journey made legible?