A single UAE onboarding flow will not survive contact with Saudi Arabia, Qatar, or Jordan. Companies that assume otherwise usually find this out during a regulatory review, not before. Shahid Hanif, CEO and Co-Founder of Shufti, argues that treating the Gulf as one regional rollout is the most expensive assumption a global identity verification vendor can make.
Shahid Hanif, CEO and Co-Founder of Shufti, a global software company that provides AI-powered digital identity verification, anti-money laundering (AML) screening, and compliance services, has spent years watching global companies stumble over the same assumption when they expand into the Middle East. Many believe that a working onboarding journey in one Gulf market can simply be copied into the next. This fair mistake can have severe consequences for a business.
In this interview, Hanif breaks down why the UAE, Saudi Arabia, Qatar, and Jordan each run their own credential systems, data transfer rules, and eKYC requirements, and why DIFC and ADGM alone mean a single UAE cloud region rarely satisfies every regulator a company answers to. He also discusses what happens when Arabic-script documents meet OCR systems built for Western IDs, what a failed document read actually costs a business beyond the rejection itself, and why Federal Decree-Law No. 10 of 2025 has quietly left many AML programmes referencing outdated legislation.
You describe the Middle East region as “nine markets, nine regulators, nine credential sets.” Could you briefly walk us through what breaks first when a team tries to treat the GCC or the wider Middle East as a single regional rollout rather than nine separate builds?
I have seen companies make this mistake more than once. They launch in the UAE, get the onboarding journey working, and then assume they can take the same setup into Saudi Arabia, Qatar, or another Gulf market with a few minor changes. Usually, the first problem is the identity layer.
The UAE is built around credentials such as Emirates ID and UAE Pass, while Saudi Arabia has Nafath and Iqama. The identity infrastructure and customer journey are different, so you cannot simply copy the UAE setup.
Then you have the regulatory and data requirements. Qatar has its own eKYC requirements, Jordan has specific expectations around biometrics and liveness, and Saudi Arabia has different rules around data transfers.
The key is to build one regional platform while still treating each market as its own identity and compliance environment. Otherwise, the gaps usually become visible when you are already at scale or facing a regulatory review.
Many different regulatory regimes pull a vendor’s infrastructure decisions in opposite directions, and how can companies operating in several GCC countries manage those discrepancies?
They absolutely can. You can have one product, one technology architecture, and still get very personalized answers in Dubai and Riyadh.
Across much of the region, international data transfers are possible when certain conditions are met, such as adequate protection, appropriate safeguards or consent. Saudi Arabia has a more specific framework under M/19, where outbound transfers can involve additional requirements such as safeguards and risk assessments.
From a practical perspective, keeping processing in-country can often be the simpler approach.
I would encourage companies to have this conversation with their technology and compliance providers very early. Do not wait until procurement is finished and then start asking where the data will be processed.
I would ask very direct questions – Can you deploy in-country? Can you support an on-premises deployment? Can you keep personal data within the relevant jurisdiction?
Even when a cross-border transfer is permitted, the business still has to demonstrate to the regulator that the relevant conditions were met. The responsibility ultimately sits with the company.
Making these decisions early gives you a much better chance of building one architecture that works across your markets. Leave them until later, and you can end up rebuilding parts of the infrastructure country by country.
Your recent report on national digital identity systems also notes that there is no single rulebook for UAE: DIFC and ADGM run their own data regimes alongside the federal law. How common is it for global teams to assume one UAE cloud region satisfies every regulator they’ll actually answer to?
It is very common, and I understand why companies make that assumption.
A global team looks at the UAE federal data protection law, Decree-Law 45 of 2021, sees that it does not generally require localisation, chooses a UAE cloud region and assumes the data question has been solved.
The UAE is more complicated than that in practice. DIFC has its own data protection law, while ADGM has its own regulations and regulator. A company can therefore satisfy the federal framework and still have additional requirements to meet depending on where it operates and which regulator it falls under.
Crypto adds another layer. Depending on where a business is licensed, it could be dealing with VARA, the FSRA in ADGM or the DFSA in DIFC, each with its own expectations around due diligence and compliance.
The best approach is to establish exactly which regulators you will be accountable to before making decisions about your architecture.
It sounds like a simple exercise, but it is one that companies often skip. Spending a few hours mapping those requirements at the beginning can save months of rework later.
What makes Arabic-script IDs harder for general OCR systems to read compared with OCR trained specifically for regional documents? Is it the writing direction, layout, or the way information is structured?
It is really a combination of all three. Arabic is written from right to left, and the characters are connected, with their shape changing depending on where they appear in a word. Diacritics can also carry meaning, but a system primarily trained on Latin scripts can easily treat them as noise.
The document layout creates another challenge. Many IDs in the region are bilingual, with Arabic and English appearing in different parts of the document. The fields do not always line up, and the structure can vary between issuing authorities.
This is where document-specific training makes a real difference. Our OCR reads Arabic-script IDs at around 94%, compared against ~64% with legacy engines.
You cannot take a system designed primarily around Western documents and simply add Arabic support at the end. Regional documents, scripts and layouts need to be part of the technology from the beginning.
Beyond raw accuracy, what does a failed document read actually cost a business?
The highest cost is not the failed document itself. It is everything that happens after failure.
In many cases, the person whose document fails is a genuine customer who has already decided to do business with you and is halfway through the onboarding process. Some people will try again, but many will simply leave. Most businesses never get a clear picture of how many customers they lost at that point.
There is also a very real operational cost. Someone has to manually review the case, or the customer has to contact support to resolve an issue that should have been handled automatically. Neither approach scales well when volumes increase.
The compliance impact is often overlooked as well. A poor document read, or an incomplete rejection, can leave gaps in the customer record. Those gaps become important when a regulator or auditor looks at how the onboarding process was handled.
In the region, typical pass rates can be around 75–92%. We are around 96% overall and close to 99% with docless verification.
For a business processing hundreds of thousands or millions of customers, a few percentage points make a significant difference. They affect conversion, operational costs, and ultimately revenue.
You draw a distinction between reading a document and verifying against a national eID rail. What makes checking Nafath or UAE Pass directly more resistant to fraud than checking an uploaded ID image?
The fundamental difference is what you are actually verifying. With an uploaded ID, you are looking at an image and asking whether the document appears genuine. With Nafath or UAE Pass, you are connecting to a trusted national identity infrastructure and asking it to confirm that the identity exists in its records. The second approach gives you a much stronger source of truth.
An attacker can create a convincing document or even a sophisticated deepfake, but creating a corresponding identity in a government identity system is a very different challenge. Verifying against the source therefore removes a number of the traditional attack methods.
There is also a strong customer experience benefit. If someone already has a national digital identity, you can remove the document capture step and potentially complete the verification in seconds. Our docless deployments are running at close to a 99% pass rate.
I would not position digital identity as a replacement for document and biometric verification. It should complement those methods. Not every customer will have access to the same national eID infrastructure, so businesses still need other verification methods to provide complete coverage.
Federal Decree-Law No. 10 of 2025 replaced the 2018 AML law in the UAE as of October 14. For firms onboarding customers in the region, what’s the practical risk, and what should be first on their list to update?
The biggest risk is actually that nothing appears to change immediately.
Decree-Law 10 of 2025 came into force on 14 October 2025 and replaced the 2018 AML law that businesses had been referring to for years. Your onboarding system does not suddenly stop working because the legislation has changed, so outdated references can easily remain in place.
The problem comes when a regulator asks what legislation the AML programme is based on and the company’s policies, procedures, contracts or board documents are still referring to the old law.
I would start with a straightforward review of the company’s internal documentation. Look at policies, procedures, contracts and governance documents and update any references to the previous legislation.
I would then review the eKYC setup against the Central Bank’s guidance on digital identification for customer due diligence.
Finally, I would make sure the onboarding journey properly supports residents, not just citizens. Expatriate residents represent a very significant part of the UAE’s population, so they should be part of the primary customer journey rather than being treated as an exception.
If you had to name the single most common mistake you see global firms make when they expand into the Middle East, one assumption carried over from a Western or APAC deployment that doesn’t survive contact with this region, what would it be?
I would say the biggest mistake is assuming that the typical customer is a citizen.
In many markets, the national ID and national digital identity cover most of the population. Companies naturally build their primary onboarding journey around those credentials and treat everyone else as an exception.
The Gulf is different. A significant part of the population consists of expatriate residents, and their identity documents and verification journeys are different from those of citizens.
When the main journey is designed around the citizen experience, a large part of the actual customer base can end up sitting in the exception queue. Companies then start seeing unexplained drop-offs and lower conversion rates without necessarily understanding why.
I see the same issue at a regional level. Companies assume that if a rollout worked in one Middle Eastern market, they can simply replicate it in the next one.
In practice, every market brings its own identity credentials, eKYC requirements, and approach to data. The technology can absolutely be regional, but the identity and compliance layer needs to reflect the local market.
We have taken that approach at Shufti from the beginning. We build for a global market, but we make sure the identity and compliance infrastructure understands the local reality of each jurisdiction.
