In regulated industries like banking, "other banks do it this way" gets treated as a load-bearing argument far more often than it should. The reasoning is understandable — banks share regulations, share customer journeys, share compliance obligations, so convergence on similar products is natural. But convergence isn't the same thing as correctness. A pattern repeated across an entire industry can be a genuinely proven practice, a regulatory necessity, or it can simply be a decision nobody has revisited since the system that first implemented it was new. From the outside, those three look identical. Only asking why tells them apart.
"This is how other banks do onboarding" answers is this common. It says nothing about is this the most secure, least exploitable, best-fit approach for what we're actually trying to prevent. Those are different questions, and treating the first as a stand-in for the second is exactly how weak patterns propagate without anyone deciding to adopt them on purpose.
The right questions for any onboarding requirement look more like: does this reduce fraud in a way we can point to? Does it resist the attack methods that are actually current? Does it create exposure — data collected that becomes a liability if breached, without a corresponding security or compliance benefit? Does current guidance still support this, or did the guidance move on while the requirement stayed put? Security questions and mandatory password rotation were both once industry-standard. Both turned out to be patterns that survived on inertia long after the reasoning behind them stopped holding up. Nothing about "everyone does this" prevented that.
It's easy to agree with "question your assumptions" in the abstract and much harder to do it against a specific requirement sitting in your own onboarding flow. Two common ones are worth walking through directly, because both turn out to hinge on something templates rarely question: not whether to collect something, but where it sits relative to everything else in the flow.
Why does onboarding ask for next of kin, and why does it ask now? This is worth real scrutiny — not necessarily to remove the field, but to question where it sits in the flow. Standard KYC and AML guidance — the frameworks that actually drive most mandatory onboarding fields — centers on verifying who the customer is and what risk they present: legal name, date of birth, address, government ID, beneficial ownership for entities. Next-of-kin doesn't verify identity and doesn't feed a fraud or AML risk model; its real justification is usually operational, borrowed from insurance and legacy retail-banking products — knowing who to contact for a dormant account or an estate after a customer's death. That's a legitimate reason to collect it. It is not, however, a reason to collect it before the account exists.
Once the requirement is understood that way, the sequencing question answers itself: next of kin doesn't gate identity verification or account creation the way a government ID or a phone-risk check does, so it doesn't belong in the same critical path as those steps. A stronger design treats it as a post-login profile-completion task — surfaced to the customer once they can already authenticate, framed as "finish setting up your account" rather than bundled into the identity-critical funnel where every extra field is measured against abandonment. This is the same instinct that makes onboarding friction dangerous in the first place: every field added to the front of the funnel is friction against the steps that actually determine whether the account should exist at all, and a field that doesn't gate that decision shouldn't be allowed to add drag to it. The mistake isn't collecting next of kin. It's treating "we need this eventually" and "we need this before you can log in" as the same requirement, when they're not.
Why verify a phone number before starting eKYC — or should it come last instead? The instinct to check a phone number early makes sense as a cheap filter: reject an obviously bad number (VoIP, recently SIM-swapped) before spending money on document verification and liveness checks. But there's a stronger version of this control that only becomes available if phone verification comes last, after device fingerprint, ID document, and face match have already been captured.
Here's why the ordering matters. Once a device, an ID, and a face have already been bound together earlier in the flow, the phone verification step stops being an isolated check and becomes a correlation point. A device that's already associated with ID Y and face U attempting phone verification and failing tells you something specific depending on how it failed: dropped at the OTP step could mean the number was recently swapped, that delivery genuinely failed, or something else worth a closer look — and if that same device then cycles through several different phone numbers trying to find one that gets past verification, that pattern is a far stronger fraud signal than any single number's risk score in isolation. A phone number checked in isolation, before any device or identity binding exists, can only be judged against generic signals like line type or carrier history. The same check run after device-ID-face binding can be judged against a specific, already-established identity claim — and a device burning through multiple numbers against one claimed identity is exactly the kind of pattern that justifies blocking the device outright rather than just rejecting one number.
That's a genuinely different design than "verify the phone early to save money on document checks," and it's arguably the stronger one for fraud detection specifically, even though it accepts the cost of running device and document capture before knowing whether the phone number will hold up. Which trade-off wins depends on what a given bank is optimizing for — cost containment on the expensive steps, or maximizing the fraud signal available at the point phone verification actually happens. Neither answer is "obviously correct" in the abstract. What matters is that the choice gets made deliberately, with the correlation trade-off understood, rather than defaulting to whichever order a template shipped with.
The lesson from putting these two side by side isn't "legacy fields bad, verification steps good." Neither turns out to be a keep-or-cut decision at all — both are sequencing questions that only reveal themselves once someone asks where a step sits relative to everything around it. Next of kin doesn't gate anything, so it belongs after login, as a profile-completion task. Phone verification gates a fraud decision, but which fraud decision it can support depends entirely on what's already been established before it runs — a phone check with no device or identity binding behind it can only judge the number in isolation, while the same check placed after device-ID-face capture can catch a device cycling through numbers against one claimed identity, which is a meaningfully stronger signal. The only way to find the right position for a given requirement is to ask what it depends on and what depends on it, rather than accepting "this is standard" — or even "this is standard, early" — as a complete answer.
Customer onboarding determines who gets an account, what identity gets trusted, and what data enters the system in the first place. A weak onboarding process creates fraudulent accounts, identity theft exposure, and mule-account risk that no amount of downstream authentication hardening can fully undo — you can't retroactively verify an identity that was never properly checked at the door. That's also exactly why onboarding is such fertile ground for inherited, unexamined requirements: it's high-stakes, expensive to redesign, and every field in it was, at some point, someone's deliberate decision — even if that someone left the organization a decade ago and the reasoning left with them.
Business continuity deserves the same scrutiny and rarely gets it. Most onboarding design centers on the happy path: identity provider responds, fraud checks clear, document upload succeeds. Real systems need an answer for what happens when the identity provider is down, when fraud scoring is unavailable, when a legitimate customer's device or number has changed since registration. A flow copied from a template that never had to answer those questions inherits that gap along with everything else.
If ten banks implement the same onboarding pattern, the eleventh bank doesn't inherit their security by copying it — it inherits their assumptions, unexamined, plus whatever has changed in the threat landscape since those assumptions were made. The standard to evaluate against is evidence, current guidance, and an honest threat model specific to what's actually being built — not how many other institutions happen to be doing the same thing. Common and secure sometimes overlap. When they do, it's worth being able to say why, the same way it's worth being able to say why when they don't.
A Secure Implementation Cannot Save an Insecure Product Decision
A team can build a specification flawlessly and still ship something insecure, if the specification itself was built on a security assumption that stopped being true years ago.
AI Knows Your Language. It Doesn't Know Your Business.
Used well, AI makes engineers faster. Used carelessly, it quietly replaces engineering judgment with statistical pattern matching — and organizations are starting to let that happen without noticing.