The Application
Pack.

In wealth management, the "application pack" is the bundle a new client completes to open and fund a managed account. It is three jobs stitched into one journey — and each is a distinct design and regulatory problem. This report benchmarks how the field solves them, where clients fall out, and what that means for Alpheya's onboarding.

Onboarding is where wealth firms quietly lose the clients they spent the most to win. The pack is long, it is regulated, and it asks for money and identity documents at the exact moment a prospect's confidence is most fragile. The industry data is blunt about the cost of getting it wrong.

Two structural truths sit under those numbers. First, abandonment clusters at friction points — identity capture, document upload, and anything that asks the client to leave the flow and fetch information. Second, the causes are operational, not cosmetic: 86% of firms blame poor data management and siloed processes, 77% blame delays, 45% blame process complexity.¹ For an HNW/UHNW book, the stakes invert the retail logic — the accounts are fewer and far larger, so a single abandoned UHNW onboarding is not a rounding error, it is a lost multi-year mandate.

The pack is not paperwork. It is the first, and most quantifiable, test of whether the relationship survives contact with your operations.

Across advised platforms (FNZ, Transact, Nucleus/abrdn Wrap, 7IM), advisor-tech (Advisor360°, Docupace, AdvisorEngine) and MENA digital wealth (Sarwa, Wahed, ENBD), the pack resolves to three sequential jobs. The best implementations make them feel like one continuous flow with a single progress spine; the worst treat them as three disconnected form-fills with re-keyed data between them.

How Client, Account, Illustration & Transfer relate

These are not four parallel steps — they are four entities with a strict dependency order. Client is the root; everything else hangs off it. The account (the wrapper) is the hub that actually gets illustrated, funded and managed. Illustration and transfer both attach to an account, never directly to the client. Reading order:

What depends on what

• Client is the root. Nothing — no account, illustration or transfer — can exist without a client to own it.
• Account is the hub. The wrapper is what gets illustrated, funded and managed; illustration and transfer attach to the account, not the client.
• Illustration describes an account. It projects the outcome and cost of that specific wrapper + mandate, so it can only be produced once the account (and any transfer value) is known.
• Transfer funds an account. It moves assets from a ceding provider into a destination wrapper — which must exist first as its target.

The six UK cases in §10 are simply different states of these dependencies — client new or already on file, account new or already held, transfer present or not. The entities and their order never change; only which ones already exist.

Three ways in — the entry models

The dependency graph is fixed, but you can enter it from three different starting points. All three converge on the same end state — a signed application over a client-owned account with an attached illustration — they differ only in what the user creates first and what the system back-fills.

All three land in the same place. The start is a product / UX choice; the finish — a signed application over a client-owned account with an illustration that reflects the final account, mandate and transfer — is fixed by the dependencies.

This is the stage every platform claims to have "digitised", and the stage where the widest quality gap actually exists. FNZ positions the ceiling: fully digital self-onboarding that opens an account in minutes, across any device, with paperless processing, automated KYC questionnaires, e-signature, online identity verification and tailored product recommendations.² The reality for advised HNW books is more nuanced — an adviser typically walks a client through account opening over one to three meetings,³ so the interface must serve a co-piloted flow, not just self-service.

The patterns that separate good from painful

• Pre-population over re-keying. Leading advisor-tech (Docupace, Advisor360°) pre-fills forms from CRM data and syncs automatically, so the client is confirming data, not typing it. Re-keying between stages is the single most cited driver of drop-off.
• Progressive disclosure of KYC. Ask only what's needed to advance, defer the rest. The "70% abandon KYC over three minutes" finding is really a finding about front-loading too much at once.
• Document capture that tolerates reality. Photo-of-passport with liveness beats a raw file-upload field. HNW onboarding adds source-of-wealth and source-of-funds evidence — high-value but high-friction, and best staged after the client is emotionally committed, not on screen one.
• Party & entity modelling as a first-class object. UHNW rarely open a simple single account. Joint holdings, corporate entities, trusts, foundations, and multiple authorised signatories are the norm — the account object must express them without forcing a separate "pack" per party.
• Suitability woven in, not bolted on. Risk profiling, capacity-for-loss, knowledge & experience and mandate selection (discretionary / advisory / execution-only) shape everything downstream, including which illustration is even permissible.

Funding is where a slick account-opening experience goes to die, because the process leaves your four walls. A client can open an account in minutes and then wait six weeks for their money to arrive — and if the interface goes silent in that gap, the firm inherits all the anxiety and none of the control.

Two ways to bring assets in

The rails you're actually riding

Transfers run on shared industry infrastructure, not bilateral phone calls. In the UK the automated re-registration schemes are Origo, Calastone and Altus, with TeX (TISA Exchange) providing the electronic framework for moving wrappers and assets between managers, platforms and wealth firms.⁵ The Origo Transfer Service — live since 2008 — has processed over a million transfers in real time.⁶ TeX covers cash and in-specie transfers of pensions, ISAs and General Investment Accounts.

A simple in-specie transfer usually takes about six weeks. It is not uncommon for it to exceed 45 working days, and complex cases can run six months or more.⁴

What the interface must do while the rails grind

• Make the invisible visible. A transfer tracker with named stages (Requested → Ceding provider notified → Assets identified → In transit → Settled) turns a scary silence into a predictable pipeline. This is the highest-leverage screen in the entire pack and the one most firms neglect.
• Set the six-week expectation up front — under-promising here protects the relationship far more than a hollow "instant" claim.
• Handle partials. Some assets re-register, some can't (unsupported funds, illiquid lines) and must go as cash. The UI has to show a mixed, part-complete transfer without looking broken.
• Surface exceptions with a human. When a ceding provider rejects or an asset is incompatible, route to an adviser/ops contact rather than a generic error.

The illustration is where the industry splits into two philosophies: the UK's regulated disclosure document and the digital-wealth world's interactive projection surface. The strongest products fuse them — a compliant artefact rendered as something a client actually wants to explore.

The UK regulatory backbone — Key Features Illustration (KFI)

Under FCA COBS 13, a KFI must include appropriate charges information and, for a packaged product that is not a financial instrument, a standardised deterministic projection.⁷ The assumptions are not the firm's to invent:

• Growth is shown at a mandated intermediate rate, with higher and lower rates set exactly ±3 percentage points around it.⁸
• For pension products the intermediate rate is capped at 5% (before any inflation adjustment), and a lower rate must be used where more appropriate to the underlying funds.⁸
• Every projection must be paired with an effect-of-charges table and reduction-in-yield (RIY) disclosure, in matching nominal or real terms.⁹
• Stochastic (Monte-Carlo) projections are permitted only if the client can reasonably understand them — and the most prominent projection must remain the standardised deterministic one.⁹

The design implication is precise: you cannot "make the numbers friendlier". You can only make mandated, sometimes sobering, numbers legible — which is a typography, hierarchy and plain-language problem, not a maths one.

The digital-wealth philosophy — the projection surface

Robo and goal-based platforms treat projection as an interactive tool rather than a PDF. State-of-the-art implementations run Monte-Carlo simulations to express goal-success probability, and let clients see in real time how adjusting contributions or extending the timeline changes the odds.¹⁰ The recurring best-practice themes:

• Probability over false precision — "78% likely to reach your goal" reads more honestly than a single deterministic line, and better matches how outcomes actually behave.
• Live "what-if" levers — contribution, time horizon, risk level — with the chart responding instantly. This turns disclosure into engagement.
• All-in fee honesty. A headline 0.25% management fee can effectively be 0.40%+ once underlying fund costs are included;¹¹ the trusted platforms show the fully-loaded number, not the marketing one.

Alpheya's two core markets pull the pack in different directions. The UK is disclosure-heavy and rail-rich; MENA is identity-heavy, multi-currency, and Sharia-aware. A single global template will over-serve one and under-serve the other.

How the platforms Alpheya tracks handle the three stages, based on their positioning and published capability. Read this as "where each sets the bar", not a feature-by-feature audit.

Distilled from the benchmark and the drop-off data — the moves that consistently separate a pack that converts from one that leaks.

• One spine, three jobs. A single persistent progress rail across account → transfer → illustration, so it reads as one relationship, not three forms.
• Confirm, don't collect. Pre-populate from CRM/known data; make the client verify rather than type.
• Three-minute KYC rule. Front-load the minimum; defer heavy evidence (source-of-wealth) until after emotional commitment.
• Save-and-resume by default. UHNW packs are never finished in one sitting — magic-link resume is non-negotiable.
• Model parties as objects. Joint/entity/trust/multi-signatory built in, not bolted on.
• Make the transfer visible. A named-stage tracker is the single highest-leverage screen; set the six-week expectation honestly.
• Design the partial transfer. Mixed in-specie + cash, part-complete, without looking broken.
• Probability over precision. Where regulation allows, lead with goal-success odds and live what-if levers.
• Show the all-in fee. Fully-loaded cost, not the headline management fee.
• Design the exception, not just the happy path. Manual review, EDD/PEP holds, ceding-provider rejections — each needs a warm, human-routed state.

The pack is one structure, but it routes very differently by client type, market and funding method. Five primary journeys cover the bulk of an HNW/UHNW book across Alpheya's mandate types; the exception paths that follow are the branches any of them can drop into. Key steps carry a teal edge; regulated / hold steps a red edge.

Two artefacts form the spine of every journey below — Create illustration (model the outcome, disclose the cost) and Create application (assemble the account, transfer instruction and declarations into the submittable pack). The order is fixed: the illustration always precedes the application — you show the client what to expect, then convert that into what they sign.

Exception & branch paths

These are shared across every flow above — the moments where the happy path forks. The field consistently under-designs them, which is exactly where the drop-off data comes from.

Zooming into the UK. On an FCA-regulated advised platform, "new business" is not one flow but a small matrix: is this a new or existing client, and are we opening a new wrapper or adding to one the client already holds? Cross that with how the money arrives — a fresh contribution or a transfer / re-registration from a ceding provider — and six real cases fall out. Where §09's journeys are representative personas, this section systematises the permutations, each with its own detailed flow.

The UK new-business spine

Every case below is a subset of one skeleton. Existing-client cases skip identity and full suitability; existing-wrapper cases skip "open wrapper"; contribution cases collapse the transfer tail. The two pack artefacts — Create illustration (KFI) then Create application — sit in the middle of all of them.

The permutations

Note — the seventh cell, new client + existing account, has no path: a brand-new client holds no wrapper on-platform yet. Its real-world equivalent is UK-2, where the "existing" account lives at the ceding provider and is re-registered in.

Alpheya already owns the downstream portfolio-creation flow — parties, client profile, financial info, risk, constraints, goals, allocation by mandate, optimiser, simulation, documents, signature, approval, activation. The application pack is the front door that feeds it. These recommendations connect the two.