Signup and Onboarding for Regulated Account Opening

Across the account-opening flows I have instrumented since 2021, between 38 and 61 percent of the people who submit the first registration form never finish identity verification. Nothing else in a signup comes close. Field order, button copy and progress indicators together move a fraction of what the verification and first-deposit steps move, and you will hear that from me before you pay to test them. This is account opening for products that must establish who the customer is: licensed sports betting and poker in France, crypto services operating under MiCA, and anything where a regulator fixes the order of the steps. The design question is never how to remove a check. It is which checks the law puts there, which ones the vendor's default implementation put there, and which ones your risk team added in 2019 and has not revisited since. The flow gets rebuilt as a state machine keyed on account id, not as a session funnel. People abandon on a Tuesday, come back on Friday from a different device and finish; a session funnel records that as two failures and one orphan success, which is how programmes end up optimising a number that does not exist. Events come from your server rather than the browser, because in France the consent banner hides a large share of client-side traffic and the hidden share is not a random sample of the rest. At the verification step I read the vendor's own rejection codes — Sumsub, IDnow, Onfido and Veriff all expose them — broken out by document type, device and capture method. The recurring findings are dull and expensive: HEIC files from iPhones rejected without a message the user can act on, camera capture blocked inside an in-app browser, proof-of-address rules that no French renter satisfies on the first attempt. Clearing the three worst rejection codes usually beats any layout change on the same screen. The first deposit gets the same treatment from the acquirer's side. On French cards, the split between CB and international rails, the 3-D Secure challenge rate and the share of authentications completing frictionless are decided by exemption strategy and acquirer configuration, not by your checkout layout. I read authorisation and authentication data with your PSP before proposing anything visual. On crypto onboarding the equivalent pair is the source-of-funds questionnaire and sanctions screening. False positives on common surnames get logged as churn instead of as a screening threshold that needs tuning, and the questionnaire usually sits where it does the most damage — before the user has any reason to trust the product with an answer. Not included: writing or approving compliance copy, changing a verification requirement without your compliance owner's written position, KYC vendor procurement, and anything to do with bonus mechanics designed to bury wagering terms. I also do not run a fixed number of tests per month here. Most account-opening steps at a mid-sized operator carry too little weekly volume to decide a five percent effect, and I would rather ship a fix with a pre/post design and a holdout than call noise a win. Not for you if: you are pre-launch with no live registrations, you need the deck rather than the change, or you are hoping I will find a route around an ANJ or AMF obligation. What you get: the instrumented state machine running in your own stack, a ranked change list where every item carries an expected effect, the evidence behind it and a named owner, and an analysis plan for the two or three steps that do carry enough volume to test properly.