Embedded finance promises that customers get financial products without leaving your product. Compliance is where that promise usually breaks. The platform experience is two taps, and then the customer is asked to upload a trade licence, photograph an Emirates ID, complete a liveness check and answer questions about beneficial ownership. Completion rates fall off a cliff, and the team’s instinct is to remove steps.
Removing steps is rarely available. What is available is doing the same checks with far less friction, by sequencing them against risk, collecting what you already hold, and running verification in parallel with the customer’s progress rather than in front of it.
Key Takeaways
- Sequence checks by risk. Not every customer needs every check at signup, and applying the strictest path to everyone is what destroys conversion.
- Never ask for data you already hold. Platform data can pre-fill most of an application, and every pre-filled field is a step removed.
- Run verification asynchronously. Let customers continue while checks complete in the background, and gate only the regulated action.
- Manual review is a permanent capability, not a temporary gap. Design the queue and the tooling from the start.
- Screening is not a one-time event. Ongoing monitoring and periodic refresh are obligations, and retrofitting them is expensive.
Sequence by risk, not by convenience
Risk-based approach: calibrating the depth and timing of customer due diligence to the assessed risk of the customer and the product, rather than applying an identical process to everyone.
The single largest conversion gain in most onboarding flows comes from recognising that a low-risk customer taking a small, low-limit product does not need the same treatment at the same moment as a high-value corporate account.
In practice that means a tiered design. A base tier with core identity verification and limited functionality. Enhanced checks triggered by thresholds, product type, or risk signals. Full enhanced due diligence reserved for the cases that genuinely warrant it, including politically exposed persons, high-risk jurisdictions and complex ownership structures.
The tiering must be defensible, documented and agreed with your compliance function or your licensed partner’s, because a risk-based approach is a regulatory concept with expectations attached, not a licence to skip work. But applied properly it means most customers experience a short flow and the effort concentrates where the risk actually is.
Use the data you already have
An embedded proposition has an advantage that a standalone financial product does not. You already know the customer. You have their identity details, their trading history, their contact information and often their business registration from when they joined the platform.
Every field pre-filled from what you hold is a field the customer does not type. Every document already on file is a document they do not upload. The onboarding flow becomes confirmation rather than collection, which is a fundamentally different experience.
Two constraints apply. Data collected for one purpose cannot automatically be reused for another under the UAE’s Personal Data Protection Law, Federal Decree-Law No. 45 of 2021, so the lawful basis and the consent position need to be right. And pre-filled data still needs verification to the required standard, because holding a value is not the same as having verified it.
Verify asynchronously
Most onboarding flows are built synchronously. The customer submits, waits for every check to return, and receives an outcome. When a check takes thirty seconds, that is tolerable. When one requires manual review, the customer is staring at a spinner or an apologetic message, and a meaningful share of them leave.
Decouple it. Accept the application, tell the customer clearly what is happening and when they will hear back, let them continue using everything that is not gated, and run the checks in the background. Gate only the specific regulated action, whether that is drawing funds, transacting above a threshold or receiving a payout, rather than gating access to the product as a whole.
This requires state management that most teams underbuild: an application that can sit in partially verified states, a customer-facing status that is honest about what is pending, and notification when the position changes. It is more engineering than a synchronous flow, and it is usually the highest-return work in the entire onboarding build.
Plan for manual review from day one
Automated verification will not resolve every case. Document quality varies, names transliterate inconsistently between Arabic and English, screening produces false positives against common names, and corporate structures with layered ownership frequently need a human to read them.
That means a review queue, tooling that shows the reviewer everything they need without switching systems, defined service levels so cases do not sit unattended, an audit trail of who decided what and why, and a clear escalation path. Teams that treat manual review as a temporary gap to be automated away later end up handling exceptions in shared inboxes, which is both slow and, from a records perspective, indefensible.
Name transliteration deserves particular attention in this region. The same individual may appear across documents in multiple valid English renderings of an Arabic name. Matching logic that expects exact strings will generate false negatives on screening and false positives on duplicates, and both are compliance problems rather than data quality annoyances.
Onboarding is the start, not the end
Sanctions and PEP screening is a continuing obligation, not a check performed once. Lists change, and a customer who was clear at onboarding may not be next quarter. That requires ongoing screening against updated lists, with alerts routed into the same review queue.
Periodic refresh of customer due diligence, transaction monitoring against expected behaviour, and defined handling for changes in beneficial ownership all belong in the design from the start. Retrofitting ongoing monitoring onto a system built only for point-in-time onboarding is a substantial rebuild, because the data model usually did not anticipate a customer record that changes state over time.
The same architecture serves the wider proposition, whether that is embedded lending or embedded payments, and it is covered in more depth on our digital onboarding and KYC page.
Frequently asked questions
How much can we realistically reduce onboarding friction?
Substantially, but through sequencing and pre-fill rather than through removing checks. The gains come from asking fewer questions because you already hold the answers, deferring checks that are not needed yet, and not making customers wait for asynchronous processes. The regulated checks themselves are not negotiable.
Who is responsible for compliance in a partner model?
The licensed partner holds the regulatory obligation, but the operational reality is shared, and their standards govern your customer experience. Agree explicitly who performs each check, who reviews exceptions, what the service levels are and who can override, because ambiguity here surfaces as delays your customers experience under your brand.
Can we onboard corporate customers with the same flow?
No. Corporate onboarding requires entity verification, beneficial ownership identification and authorised signatory verification, which is a different and longer process. Attempting to force it through a consumer flow produces a poor experience and incomplete records. Build it as its own path.
What about Emirates ID verification?
Emirates ID is the primary identity document for UAE residents and supports document and biometric verification approaches. What matters architecturally is designing for multiple document types from the start, since a platform serving the GCC will onboard customers holding a range of national identity documents and passports.
How long does an onboarding build take?
A tiered flow with automated verification, asynchronous processing and a functioning review queue is typically twelve to sixteen weeks. The verification integrations are the quick part. The state management, review tooling and ongoing monitoring are what determine the timeline.
Onboarding losing customers to compliance?
Kentro builds risk-tiered onboarding and KYC for embedded finance across the UAE and GCC, including asynchronous verification, review tooling and ongoing monitoring.
