When digital onboarding is not tailored to customer type, banks often force every applicant through the same steps, even when some steps are unnecessary. That creates avoidable delay, lowers completion rates, and weakens the promise of a paperless experience. A configurable workflow lets banks collect only the data and approvals needed for each onboarding scenario.
Why configurable onboarding workflows matter in digital banking
digital onboarding is not just a front-end convenience. It is the control layer that decides which checks, disclosures, approvals, and handoffs a customer must complete before they become active. When banks cannot configure that flow by customer type, product, jurisdiction, or risk profile, the process becomes rigid, slower, and harder to complete without creating friction that does not add security value.
That rigidity matters because onboarding is a decisioning process, not a single form. A retail customer, a small business, and a higher-risk relationship often need different evidence and approvals. A configurable workflow lets the bank match the journey to the scenario instead of forcing every applicant through the longest path.
It also preserves the promise of paperless onboarding. If the digital process still requires unnecessary steps, repeated data entry, or manual intervention, the experience becomes “digital” in channel only, not in outcome. The bank may have replaced paper with a slower digital queue rather than with a genuinely streamlined process.
Where the onboarding failure shows up operationally
The first visible effect is avoidable abandonment. Applicants are more likely to stop when they encounter steps that do not fit their situation, such as redundant document upload, repeated confirmation of already-known information, or approvals that should only apply to a subset of cases. Completion rates fall because the workflow is asking for too much from too many people.
The second effect is delay. Instead of routing straightforward cases through a fast path and reserving review for exceptions, the bank treats all cases as exceptions. That increases cycle time, creates manual backlogs, and shifts effort from genuine review to administrative triage. In practice, the bank spends more time processing low-risk cases without improving decision quality.
A configurable design also improves control consistency. If the workflow cannot adapt, teams often compensate with side channels, email-based exceptions, or offline checks. Those workarounds can be harder to evidence, harder to audit, and more likely to produce inconsistent treatment across branches, products, or regions.
How banks should think about configuration, not standardisation
Standardising every applicant into one fixed journey is usually the wrong kind of simplicity. The better model is consistent decision rules with configurable execution paths. The policy stays governed, but the journey can vary based on customer class, product type, risk signals, document type, or required approvals.
That is why onboarding design is closely related to identity proofing and customer due diligence. When those checks are required, they should be targeted and proportionate, not applied as a blanket burden that slows low-risk cases for no gain. Guidance from FATF Recommendations and the EBA AML/CFT Guidance both reinforce that customer due diligence should be risk-based rather than mechanically identical for every case.
For banks operating across jurisdictions, configuration also helps align onboarding with digital identity and verification expectations. eIDAS 2.0 is relevant where reusable digital identity and cross-border verification can reduce unnecessary re-keying and help the bank separate simple identity reuse from higher-friction verification steps.
Risk and Threat Considerations
Rigid onboarding workflows create both business risk and abuse risk. A process that is too long or too uniform increases abandonment, but it also creates a predictable bottleneck that fraudsters can probe for weak exception handling, rushed manual approvals, or inconsistent treatment between channels.
Failure mechanism: The bank overgeneralises one onboarding path and then compensates with manual overrides, which produces friction for legitimate customers and inconsistency in control execution.
Impact: The result is lower conversion, slower revenue realisation, weaker auditability, and a greater chance that high-risk cases are processed with the same lightweight treatment as low-risk ones.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Digital onboarding relies on identity verification and step-up checks. |
| NHI-01 — Improper Offboarding | Onboarding workflow design is part of the identity lifecycle that pairs with account creation and exit handling. | |
| Recommendation — Align verification steps to the onboarding risk and remove unnecessary authentication friction. Keep onboarding and lifecycle controls consistent so access is only granted when the full process is complete. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Onboarding depends on assurance levels, identity proofing, and verification depth. |
| Recommendation — Map onboarding paths to the required assurance level and verify the right evidence for each scenario. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Digital onboarding journeys need clear inventory and routing of steps and exceptions. |
| Recommendation — Inventory every onboarding path and confirm each route is controlled, tested, and owned. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Onboarding is an access-gating process that must match identity assurance to the requested service. |
| Recommendation — Use risk-based access gating so each onboarding journey collects only the controls it needs. | ||
Practitioner Guidance
What to prioritise: Separate the policy decision from the workflow design. Define which fields, checks, and approvals are mandatory by customer segment, product, and jurisdiction, then let the journey adapt to those rules rather than forcing a single universal path.
What to verify: Test onboarding with representative scenarios, including low-friction retail cases and higher-control business cases. If the same workflow still asks for the same evidence in every case, the configuration model is too blunt to support completion or control efficiency.
Decision rule: If a step does not change the risk decision for a given onboarding scenario, remove it from that journey. Keep only the checks that improve assurance, satisfy regulatory need, or support downstream servicing.
Practitioner takeaway: The best onboarding design is not the one with the fewest steps overall, but the one that removes unnecessary steps without weakening the checks that actually matter.
Related resources from NHI Mgmt Group
- What happens when digital banks rely on online onboarding without enough identity verification?
- What happens when banks try to scale digital onboarding without stronger e-KYC checks?
- What happens when a payments firm tries to scale onboarding without automation or identity verification?
- What happens when organisations try to pursue digital growth without a strong identity and access foundation?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
