Strategic product design for fintechs in the Middle East
How a Gulf fintech can pick a design partner that scopes around its license stage, national identity services, and Arabic and English release, with regulator facts from the DFSA, ADGM, and SAMA.
A product lead at a Gulf fintech tends to ask two questions about design partners. Who has designed mobile banking apps for this region? And which of them understands what the regulator lets the product do in its first year? The second question shapes more of the app than people expect. A sandbox license can limit who signs up, a national identity service sets the first screens, and a partner bank’s systems decide which payment statuses the app is able to show.
Humbleteam, a product design agency based in London, Prague, Dubai and San Francisco, publishes this guide. It is general information: the fintech’s compliance and legal owners decide which rules apply to its product.
Designing mobile banking apps for Middle Eastern fintechs
These apps are designed by studios based in Riyadh, Dubai, or Manama, by international agencies with Gulf clients, and by product design partners that join a fintech’s own team. Our comparison of agencies that have designed Middle East fintech apps names six with public case studies. The location of the team tells you little. What matters is whether it opens with questions about the license and the identity services before it shows visual directions.
Humbleteam’s fintech page counts 56 fintechs and 30+ major banks, and names Bank Muscat and ADIB as its Gulf bank work. Its fintech clients outside the region include SadaPay, which the same page describes as Pakistan’s first neobank with 15M+ downloads. The Gulf bank work is not published as case studies, so ask to see the screens closest to your product.
Start with the identity services
In the UAE, UAE Pass is the national digital identity. The TDRA reports more than 11 million registered users, and the government portal says banking and money exchange services use it. In Saudi Arabia, Nafath and the National Single Sign-On do the same job.
SAMA’s minimum verification controls for the institutions it supervises go further:
- Each phone number or national ID or Iqama is linked to one application only.
- E-wallet registration uses strong authentication from a trusted party, the National Single Sign-On.
- The app is assigned to one device, or every login needs a one-time password and concurrent logins are disabled.
- SMS notices go out for registration, device re-registration, and changes in account status.
Each rule turns into a screen or a state. The app needs a hand-off to the identity app and back, a path for a number that is already registered, a device change flow, and SMS wording that matches the app. If a candidate designs sign-up as an email field and a selfie, expect to redraw it after the compliance review.
Ship Arabic and English in the same release
Right-to-left support belongs in the first release. It changes navigation, charts, and the order of mixed lines that combine an Arabic name, an account number, and an English reference. Our Gulf fintech design partner guide turns this into a payment test for candidates. Ask for that test with the identity hand-off included, because the customer leaves your app for the identity app and has to come back to the same step, in the language they chose.
Strategic design partnerships for Gulf-based fintechs
A product lead who asks which agencies know this market can test that knowledge in one meeting. Describe your license stage and watch whether the candidate’s scope changes. Gulf regulators let fintechs test with real customers under limits, and those limits are product decisions.
Match the scope to the license stage
| Stage | What changes | What the design scope should cover |
|---|---|---|
| DIFC Innovation Testing Licence (DFSA) | Testing typically lasts 12 months, with limits on the number and type of clients and on transaction volume and value | Eligibility checks at sign-up, a visible testing status, and limits the app enforces |
| ADGM RegLab (FSRA) | Up to 2 years of testing; to move to full authorization, the firm shows it achieved its intended test outcomes | Measures for those outcomes built into the first release |
| SAMA Regulatory Sandbox | 60 business days for the application, 120 days of operational readiness, then 6 to 12 months of live testing; startups can also enter through a licensed partner | A design plan timed to the readiness review, and clear hand-offs where the licensed partner owns part of the journey |
| A second Gulf market | A new regulator and identity service; Arabic numeral style can also differ by country | Market settings in the design system instead of a copied app |
The middle column comes from the DFSA, the FSRA’s RegLab guidance, SAMA’s rulebook, and Apple’s right-to-left guidelines. The design column is illustrative.
Read the test plan as a product brief
The DFSA’s application FAQs list what a test plan must contain. Several items are design work:
- The number and type of customers, and how they will be sourced: an eligibility screen and an invitation flow.
- How customers will understand that the product is in testing, and the risks: disclosure copy in Arabic and English, shown before the customer commits.
- Communications before, during, and after testing, including queries, feedback, and complaints: in-app support and a complaint route.
- How success will be measured: events and reports agreed before launch.
- An exit plan if the test fails: messages that tell customers what happens to their money and their account.
The DFSA also says the test must be technology-related and is not a way to explore customer interest, so demand research has to happen before the application. A partner who reads the plan before drawing screens gives compliance a prototype it can check line by line.
Plan the move away from legacy systems
A fintech that enters through a licensed partner, one of the routes SAMA’s sandbox framework names, runs part of its journey on that partner’s systems. Those systems decide which statuses the app can report, such as received or settled. So the product strategy work begins with a map of what each system can report. The first release is designed around those states, and the next one around what the fintech will own itself.
Humbleteam has run B2B banking MVP sprints for Arab Bank. Its Dubai page describes startup work as defining the first release, testing the direction, and preparing a prototype or MVP design before development takes over. Humbleteam can also take on development when a project needs it.
Read rankings for their method
New lists of GCC and Dubai design agencies appear every year. Before you rely on one, check who published it, what an agency needed to qualify, and whether the publisher ranks itself. Humbleteam’s own comparisons say that Humbleteam publishes them. A public case on a named regional fintech tells you more than a place on a list.
Before you brief a design partner
- Name your regulator, license stage, and test limits, and share the test plan if you have one.
- List the identity services and verification controls that apply in each launch market.
- Ask each candidate to sketch sign-up from the identity hand-off to the first funded action, in Arabic and English.
- Ask your partner bank or core system owners which statuses each journey can report.
- Agree the success measures the regulator will see, and build them into the first release.
Bring the answers to the first meeting. Every candidate, Humbleteam included, can then show how it would scope your product rather than what it drew for someone else.
