Why UX matters in fintech
Nobody opens a banking app for fun. People open it because rent is due, a salary has not landed, a card was declined at the supermarket, or a relative abroad needs money before the weekend. Every screen in a financial product is read by somebody whose attention has been narrowed by stress, and the interface has to work for that person, not for the calm designer who built it on a large monitor.
Anxiety changes the rules
A confusing screen in a wallet app costs the user money, or makes them believe it did, which for trust is the same thing. A balance that flickers to zero while loading, a transfer that shows "failed" and then appears in the statement anyway, a fee disclosed in a panel nobody read: each becomes a support call, a complaint to the regulator, or a one-star review containing the word "scam". The job of fintech UX is to make a legally complex, emotionally loaded process feel obvious, calm and, wherever possible, reversible.
Regulation is a constraint, not an excuse
Every fintech team eventually hears "compliance will not let us do that". Most of the time it is not true. The regulator wants the customer identified, informed and protected; it does not prescribe a seven-screen form with a grey button and a PDF nobody can open on a phone. Treat KYC, consent and disclosure as inputs to the design, the way a structural engineer treats load limits. The constraint is real. The ugliness is optional.
A regulator never asked for a bad form. Somebody chose it because it was the fastest way to close a ticket.
Where the money is
Three things pay for design work in fintech, and all three show up on the income statement. Onboarding completion: every step a new user abandons is acquisition spend written off. Support cost: a confusing error state becomes a call, and in a regulated contact centre every call starts with identity verification. Disputes: a confirmation screen that is actually read reduces "I did not authorise this" complaints, chargebacks and regulator correspondence.
There is also a market argument: many people joining digital finance in Egypt, Saudi Arabia and the UAE have never held a bank account, read Arabic far more comfortably than English, and use a mid-range Android phone on a congested network. Designing for them is the addressable market, and the products that get it right become the default, the way InstaPay did in Egypt.
Where it is used
Fintech UX is not one surface. It is a family of surfaces with different emotional temperatures, and a product that treats them all the same will be wrong on most of them.
Onboarding and KYC
The highest-stakes surface: you meet the user for the first time and immediately ask for their national ID and a selfie. A good flow says up front what will be needed, lets people stop and resume, explains why each piece of data is collected, and never leaves them staring at a spinner after the selfie.
Payments and checkout
Bill-payment aggregators such as Fawry made "pay a bill from a reference code" familiar across Egypt. Merchant checkout is where card entry, hosted fields, Apple Pay and local schemes such as Meeza or mada meet, and the job is to make paying feel certain: one clearly labelled amount, one button, and a receipt that can be found again.
Transfers and remittances
Transfers are where fear peaks, because the money leaves and the user has to trust that it arrived. Name confirmation before sending, a review screen that repeats the amount, and a status tracker afterwards are the core patterns. Wise popularised showing the exchange rate and the fee separately instead of hiding the spread; that is now the benchmark for remittances into Egypt.
Cards
Control and explanation: freeze and unfreeze, viewing the PIN safely, setting limits, enabling online or international use and, critically, explaining a decline in words the user can act on. "Transaction declined" is not an explanation; "This merchant is outside your allowed countries. Turn on international payments to retry" is.
Lending and buy-now-pay-later
Lending screens carry the heaviest disclosure load: total cost of credit, repayment schedule, what happens on a missed instalment, and consent to a credit-bureau check (I-Score in Egypt, SIMAH in Saudi Arabia, AECB in the UAE). The challenge is to show all of that without burying the one number the user wants: how much each month, for how long.
Investing and savings
Gold, funds, sukuk, equities and savings goals. Here the discipline resists gamification: performance shown with its period and comparison, risk warnings legible rather than merely present, and Shariah-compliance labels accurate and sourced, because for much of the audience that is a matter of faith.
Support and disputes
The forgotten surface. A "where is my money" tracker and a dispute flow that pre-fills the transaction details do more for retention than another onboarding redesign.
Strengths
What does a product gain when it takes this discipline seriously? Four things, each measurable.
Trust you can see
Trust in a financial product is not an atmosphere; it is a set of concrete signals the user checks before putting money in. A product can audit itself against them.
| Trust signal | What the user sees | What it tells them |
|---|---|---|
| Licence and regulator named | "Licensed by the Central Bank of Egypt", with the licence number, in the footer and About screen | Somebody is accountable |
| Fees before the final button | The exact fee and what the recipient receives, on the review screen | No surprises on the statement |
| Balance consistency | The same figure on the home screen, the statement, the push and the SMS | It is one system, not three |
| Status after every money action | "Sent", "Pending at the receiving bank", "Arrived", with timestamps | The money is somewhere, not lost |
| Plain-language security | "We will never ask for your code by phone", on the OTP screen itself | The product knows what scams look like |
Conversion without manipulation
A well-designed onboarding flow converts because it removes doubt, not because it hides the exit. Progress indication, a clear list of required documents and the ability to pause are the honest levers, and the durable ones: users acquired through pressure churn at the first fee; users acquired through clarity stay.
Fewer support tickets
Every ambiguous screen is a future ticket. Good error design, status tracking and self-service controls (freeze a card, raise a limit, download a statement) move work out of the contact centre and into the product, and where every call begins with identity verification that is a direct saving.
Compliance by design
When disclosure, consent capture and audit trails live in the component library, every new product inherits them. A compliance team that reviews one consent component once is more effective than one that reviews thirty screens a quarter.
The cheapest audit finding is the one the design system made impossible.
Risks and pitfalls
The failure modes in fintech UX are predictable, which is good news: most can be caught with a checklist.
Error messages that create tickets
An error message is customer support delivered at the worst possible moment. Most are written by a developer at the point of throwing an exception, which is why they describe the system rather than the situation. The fix is a content-design pass that makes every message answer three questions: what happened, did money move, and what should I do now.
| Situation | Before | After |
|---|---|---|
| Wrong OTP | "Invalid code" | "That code did not match. You have 2 more tries, or request a new code." |
| Daily limit reached | "Error 403: limit exceeded" | "This is above today's remaining limit. You can send up to EGP 12,500 more today, or raise your limit in Settings." |
| ID photo rejected | "Document rejected" | "We could not read your ID. Show all four corners, avoid glare, and try again." |
| Timeout during transfer | "Something went wrong" | "We are checking whether this transfer went through. Do not send it again; we will notify you within a few minutes." |
The timeout row matters most: a user who sees "something went wrong" after pressing Send will press Send again, and if the backend is not idempotent you have just created a duplicate transfer and a dispute.
Dark patterns that cost more than they earn
Some patterns convert this quarter and destroy the product over the next few years. The ones I refuse to ship:
- Hidden or drip-priced fees: a fee that appears only on the last screen or the statement. Show it on the review screen, in the same size as the amount.
- Pre-ticked consent: marketing, data sharing or a paid add-on that is on by default. Consent the user did not actively give is not consent.
- Confirmshaming: "No, I don't want to protect my money" as the decline button on an insurance upsell. Users remember contempt.
- Forced continuity: a free trial that silently becomes a paid subscription, with cancellation hidden behind support chat.
- Fake urgency and obstructed closure: countdown timers that reset, or an account that needs a branch visit to close when it needed only a selfie to open.
Money formatting mistakes
Small and everywhere. Floating-point arithmetic in the front end produces totals that differ from the ledger by a piastre. Negative amounts shown only in red, which fails colour-blind users and anyone in bright sunlight. Three-decimal currencies (Kuwaiti, Bahraini and Omani) truncated to two decimals. Arabic amounts where the minus sign lands on the wrong side because nobody isolated the bidi run.
The translated interface
Many Arabic fintech interfaces are English interfaces with the strings swapped: labels truncated because Arabic runs longer, icons pointing the wrong way, logos mirrored along with the layout, formal Arabic that reads like a legal notice, and placeholder text used as the only label so that it vanishes once the user starts typing. Arabic is not a localisation task for the end of the project; in this region it is usually the primary design language.
Friction in the wrong places
Too little friction, and a user can send their savings to a scammer with a single tap. Too much, and a user cannot pay a bill without three OTPs and a selfie. Friction should be proportional to risk: a new beneficiary plus a large amount at an unusual hour deserves a pause and a warning; the same electricity bill paid every month does not.
Architecture and integration patterns
Design in a fintech organisation is a system, not a sequence of mock-ups. These are the structural pieces that let a small team ship consistently across web, iOS and Android in two languages.
A design system with money as a first-class component
Most design systems start with buttons and colours. A fintech design system should start with an Amount component: one implementation that handles currency, minor units, sign, tabular digits, bidi isolation, size variants and a masked state for privacy. Every balance, fee, instalment and limit renders through it, so when compliance asks for the currency code next to the symbol, you change one component. Material Design and the Apple Human Interface Guidelines cover platform conventions, but neither has a money component; that part is yours to build.
Money and RTL typography rules
/* Money: tabular digits so columns, totals and running balances line up */
.amount,
.ledger td {
font-variant-numeric: tabular-nums lining-nums;
font-feature-settings: "tnum" 1;
}
/* Mixed Arabic/Latin runs (an amount inside an Arabic sentence): let each
run resolve its own direction instead of inheriting the paragraph's */
.amount,
.reference {
unicode-bidi: plaintext;
white-space: nowrap;
}
/* Logical properties: one rule serves both LTR and RTL layouts */
.ledger td {
padding-inline-start: 0.75rem;
padding-inline-end: 0.75rem;
text-align: end;
}
.amount__currency {
margin-inline: 0 0.25em; /* start, end: the gap sits after the symbol */
}
/* RTL-only adjustments that logical properties cannot express */
[dir="rtl"] {
font-family: "IBM Plex Sans Arabic", "Noto Sans Arabic", system-ui, sans-serif;
line-height: 1.7; /* Arabic glyphs need more vertical room than Latin */
}
[dir="rtl"] .iban {
direction: ltr; /* IBANs are always read left to right */
unicode-bidi: isolate;
display: inline-block;
}
[dir="rtl"] .icon-chevron {
transform: scaleX(-1); /* directional icons flip; logos and numerals do not */
}
/* Users who asked the OS for less motion get no counting-up balances */
@media (prefers-reduced-motion: reduce) {
.balance,
.skeleton {
animation: none;
transition: none;
}
}
Tested with modern browsers (2025+).
Content design as infrastructure
Treat copy the way you treat code. Every user-facing string has a key, an English value, an Arabic value, an owner and a status. Errors are written from templates. A glossary fixes the Arabic terms for "transfer", "beneficiary", "instalment" and "limit" so that the app, the SMS, the push notification and the support agent use the same word. Compliance reviews the glossary and the templates, not every screen. The GOV.UK Design System is the best public example of content standards living inside a component library.
Research operations
Research has to be continuous, not a quarterly event: a consented participant panel recruited through the product with a clear opt-in, a fixed weekly slot for sessions, a drawer of cheap Android phones, remote sessions for users outside the capital, and a protocol for low-literacy and first-time banking users. The Nielsen Norman Group heuristics remain a usable checklist for expert review between sessions.
Design-to-development handoff
The handoff artefact is not a Figma file. It is tokens exported to code, a component library that engineers consume, and acceptance criteria that include the states nobody draws: loading, empty, error, offline, partial failure, RTL, large text and reduced motion. A story is not done until the RTL screenshot and the screen-reader pass are attached.
Analytics and experimentation pipelines
Instrument the funnel per step, not per screen: each KYC step emits start, success, failure with a typed reason, and abandonment. Errors share one taxonomy across front end, backend and content, so "document_glare" means one thing everywhere. Guardrail metrics (complaints, disputes, support contacts per thousand transactions) sit next to conversion, so an experiment that lifts conversion by hurting comprehension fails automatically.
Security and compliance
Security and compliance are usually presented as the enemies of UX. In practice most requirements translate into a handful of design patterns, and most of the hostility comes from implementing them without a designer in the room.
KYC and AML from the user's chair
Customer due-diligence rules in the region come from the central banks (the CBE in Egypt, SAMA in Saudi Arabia, the CBUAE in the UAE) and follow the FATF recommendations on identification, risk-based verification and ongoing monitoring. From the user's chair those rules become a sequence of asks, and each ask needs a reason, a format hint and a recovery path.
| Requirement | UX pattern | Common failure |
|---|---|---|
| Identify the customer (ID, selfie, liveness) | Guided capture with a framing overlay, live feedback on glare, manual-review fallback with a timeline | Three silent retries, then "verification failed" |
| Verify against a national source (Egyptian national ID, Nafath, UAE PASS) | Explain the redirect, show what will be shared, return the user to the exact step | User lands on the home screen unsure whether it worked |
| Risk questions (occupation, source of funds, PEP status) | Plain-language questions with examples and an inline "why we ask" | Legal terminology with no help text |
| Consent evidence | Timestamped consent with the exact text version | A boolean flag with no text |
Strong customer authentication and the OTP screen
Whether the trigger is PSD2's strong customer authentication rules, a central bank's two-factor requirement or your own risk engine, the OTP screen is the most visible security surface in the product, and the one where accessibility and security collide: WCAG 2.2 adds a criterion on accessible authentication that asks you not to make users transcribe or remember things when a more accessible mechanism exists. Passkeys and device biometrics should be the primary factor where regulation allows, with OTP as the fallback that autofills from SMS, works with a screen reader, and says on the same screen that nobody will ever ask for it.
An accessible OTP input group
<form class="otp" novalidate>
<fieldset aria-describedby="otp-hint otp-error">
<legend>Enter the 6-digit code we sent to +20 1•• ••• 4321</legend>
<p id="otp-hint">It expires in 2 minutes. Nobody from us will ever ask you for it.</p>
<div class="otp-group" dir="ltr">
<label for="otp-1" class="visually-hidden">Digit 1 of 6</label>
<input id="otp-1" type="text" inputmode="numeric" autocomplete="one-time-code"
maxlength="1" pattern="[0-9]" aria-describedby="otp-error" required>
<label for="otp-2" class="visually-hidden">Digit 2 of 6</label>
<input id="otp-2" type="text" inputmode="numeric" autocomplete="one-time-code"
maxlength="1" pattern="[0-9]" aria-describedby="otp-error" required>
<label for="otp-3" class="visually-hidden">Digit 3 of 6</label>
<input id="otp-3" type="text" inputmode="numeric" autocomplete="one-time-code"
maxlength="1" pattern="[0-9]" aria-describedby="otp-error" required>
<label for="otp-4" class="visually-hidden">Digit 4 of 6</label>
<input id="otp-4" type="text" inputmode="numeric" autocomplete="one-time-code"
maxlength="1" pattern="[0-9]" aria-describedby="otp-error" required>
<label for="otp-5" class="visually-hidden">Digit 5 of 6</label>
<input id="otp-5" type="text" inputmode="numeric" autocomplete="one-time-code"
maxlength="1" pattern="[0-9]" aria-describedby="otp-error" required>
<label for="otp-6" class="visually-hidden">Digit 6 of 6</label>
<input id="otp-6" type="text" inputmode="numeric" autocomplete="one-time-code"
maxlength="1" pattern="[0-9]" aria-describedby="otp-error" required>
</div>
<!-- Linked by aria-describedby, so screen readers read it with the field -->
<p id="otp-error" class="field-error" role="alert" hidden></p>
<!-- Visually hidden live region: "Code accepted", "2 attempts left", etc. -->
<p id="otp-status" class="visually-hidden" aria-live="polite" aria-atomic="true"></p>
</fieldset>
<button type="submit">Verify</button>
<button type="button" class="button-link">Resend code</button>
</form>
Tested with modern browsers (2025+).
Consent and disclosure that people actually read
Layer it: a one-screen summary with the three or four facts that change the decision (fee, rate, what you share, how to cancel), a link to the full text, then a consent action that is specific ("I agree to share my credit report with SIMAH for this application") rather than global. Store the exact text version with the timestamp, and make withdrawal as easy as consent.
Fraud warnings and confirmation friction
Modern scams are social, not technical: somebody calls pretending to be the bank, the telecom or a government office and talks the victim through authorising a transfer. For a first transfer to a new beneficiary, especially a large one, show a plain warning ("Has someone asked you to make this transfer? Banks never ask you to move money to a 'safe account'"), add a short delay with a visible cancel, and require a second factor. For routine payments, stay out of the way.
Accessibility obligations
WCAG 2.2 AA is the bar regulators and procurement teams point to: contrast, keyboard and screen-reader operability, visible focus, minimum target sizes, no meaning carried by colour alone, and the newer criteria on redundant entry and accessible authentication that apply directly to KYC. Beyond the standard, many users here have low literacy in either script; large targets, short sentences, icons with labels and voice notes in support are mainstream design, not extras.
Arabic, numerals, calendars and identity formats
RTL correctness goes beyond mirroring: the layout and directional icons flip, logos and numerals do not, and mixed-direction strings (an Arabic sentence containing an IBAN or an amount) need bidi isolation or the punctuation lands on the wrong side. Numeral preference varies: Egypt commonly uses Western digits in apps, Saudi Arabia leans towards Arabic-Indic in official contexts, and both populations read both, so offer a setting and test the default. Saudi users often need Hijri and Gregorian dates side by side, so the date component handles both calendars. The W3C internationalisation resources are the reference for the bidi details.
Arabic names commonly have four parts and no single "last name"; capture the name as it appears on the ID, with a separate Latin transliteration if cards need one, because "Mohamed", "Mohammed" and "Muhammad" are the same person. Saudi Arabia has a structured National Address, while much of Egypt uses descriptive addresses that do not fit a postcode field. ID formats are public and worth validating client-side: the Egyptian national ID is 14 digits and encodes birth date and governorate, Saudi IDs and Iqamas are 10 digits, and the Emirates ID is 15 digits beginning with 784.
Performance and scaling
Performance in a financial product is about certainty as much as speed. A fast screen that shows the wrong state is worse than a slower one that is honest.
Perceived performance and skeleton states
Never render a balance as "0.00" while it loads. Use a skeleton for amounts and lists, and keep the last known balance visible with a refreshing indicator when the user returns. Optimistic updates are fine for renaming a beneficiary and dangerous for money: do not show a transfer as sent until the backend has acknowledged it. Spinners are for sub-second waits; anything longer needs a sentence that says what is happening.
Offline and poor networks
Many users in the region are on congested mobile networks. Read-only data (statements, beneficiaries, card details) can be cached and shown with a "last updated" stamp. Money-moving actions must not be queued silently: if the request cannot be sent, say so, keep the draft, and make the retry idempotent so that tapping twice does not pay twice. The PCI Security Standards Council defines what you may cache when cards are involved.
Localisation at scale
Arabic has six plural categories, so any string that counts things ("3 instalments remaining") needs a pluralisation library, not string concatenation. Pseudo-localisation in CI (expanding every string by a third and wrapping it in RTL marks) catches truncation and bidi bugs before a translator sees them. Money, dates and numbers go through the platform's internationalisation APIs with an explicit locale the product controls; the MDN reference for Intl.NumberFormat covers the options used below.
A money formatter that respects locale and currency
// Amounts travel as integers in minor units (piastres, halalas, fils). Never floats.
const MINOR_DIGITS = { KWD: 3, BHD: 3, OMR: 3, JOD: 3, JPY: 0 };
function toMajorString(amountMinor, digits) {
const negative = amountMinor < 0;
const abs = String(negative ? -amountMinor : amountMinor).padStart(digits + 1, '0');
const whole = abs.slice(0, abs.length - digits);
return (negative ? '-' : '') + whole + (digits ? '.' + abs.slice(-digits) : '');
}
function formatMoney(amountMinor, currency, locale, { showSign = false } = {}) {
const digits = MINOR_DIGITS[currency] ?? 2;
const formatter = new Intl.NumberFormat(locale, {
style: 'currency',
currency,
minimumFractionDigits: digits,
maximumFractionDigits: digits,
// 'exceptZero' prints "+" for credits and "-" for debits; zero stays plain
signDisplay: showSign ? 'exceptZero' : 'auto',
});
// A decimal string keeps the value exact (Intl.NumberFormat v3, evergreen browsers)
return formatter.format(toMajorString(amountMinor, digits));
}
// Egypt, English interface
formatMoney(125050, 'EGP', 'en-EG'); // EGP 1,250.50
// Egypt, Arabic interface forced to Western digits (the usual choice in Egypt)
formatMoney(125050, 'EGP', 'ar-EG-u-nu-latn'); // 1,250.50 ج.م.
// Saudi Arabia, Arabic interface with the locale's default Arabic-Indic digits
formatMoney(99900, 'SAR', 'ar-SA'); // ٩٩٩٫٠٠ ر.س.
// Three-decimal currencies keep every fils
formatMoney(1500, 'KWD', 'en-KW'); // KWD 1.500
formatMoney(2750, 'BHD', 'ar-BH-u-nu-latn'); // 2.750 د.ب.
// Debits in a statement row: the sign is explicit, never implied by colour alone
formatMoney(-45000, 'EGP', 'en-EG', { showSign: true }); // -EGP 450.00
formatMoney(45000, 'EGP', 'en-EG', { showSign: true }); // +EGP 450.00
// Exact symbol, spacing and bidi marks vary slightly between engines; test yours.
Tested with modern browsers (2025+).
Design-system governance
A design system that is not governed becomes a second legacy codebase. Version it semantically, run visual regression in both directions and both colour schemes, and have a contribution model so the lending team can add a repayment-schedule component without forking. Measure adoption: the share of screens built entirely from system components predicts how fast the next regulatory change can ship.
Team and hiring in MENA
The talent market for fintech design in Egypt, Saudi Arabia and the UAE has matured quickly, but unevenly. Visual design skill is abundant; content design, research and the specific craft of financial interfaces are rarer.
Roles that move the metrics
A lean fintech design team has four roles, and the order of hiring matters. First, a product designer who has shipped a transactional product: someone who draws the error states before the happy path. Second, a content designer who writes Arabic natively and English well, because the Arabic copy is where most of the trust is won or lost. Third, a researcher who can run sessions with first-time banking users. Fourth, a design engineer who owns the component library. Visual specialists come after that.
Arabic content design is a specialist skill
Translating English microcopy into Arabic produces Arabic nobody would say. Good Arabic content design writes from the Arabic first: the right register (Modern Standard Arabic for anything financial, with enough warmth to avoid sounding like a government circular), consistent terminology, and sentences that survive narrow screens. The content designer sits with compliance when disclosures are written, instead of receiving them afterwards for translation.
Research with first-time and low-literacy users
Standard usability protocols assume a participant who reads fluently and thinks aloud comfortably; many of the most important users here do neither. Recruit through community channels, run sessions on the user's own phone in their own environment, rely on observation more than questionnaires, pay incentives as mobile credit or a wallet top-up, and use a facilitator who speaks the participant's dialect. Watch for the user who nods and says "yes, clear" while their thumb hovers; the hover is the finding.
Interview signals
For product designers, I ask candidates to walk through a transfer flow they shipped and narrate what happens when the network drops after Send; strong candidates describe the pending state, weak candidates describe the animation. For content designers, I hand over a developer-written error and ask for the Arabic and English rewrites side by side; the test is whether the Arabic reads as the primary text. For researchers, I ask how they would test onboarding with somebody who has never had a bank account; the answer should mention recruiting and dialect before it mentions a tool.
Where the people are
Cairo has the deepest pool of product designers and a growing content-design community; Riyadh and Jeddah have strong demand and a fast-growing local pipeline; Dubai and Abu Dhabi attract senior talent from across the region. Remote work across the three is normal.
Decision framework
Founders and CTOs usually face the design question in one of three forms: build an in-house team, hire an agency, or adopt an existing design system and keep the team tiny. The answer depends on the stage, the number of transactional surfaces and how often regulation changes under you.
Three paths
In-house team. Highest control and continuity, slowest to start, and the only option that builds research knowledge that compounds. The right default once the product has a licence.
Agency or studio. Fast to produce a brand, a marketing site and a first version of the app. Weak on continuity, Arabic content depth and the regulatory changes that need a designer who already knows the product. Best for a launch sprint with a planned handover, or specialist work such as brand.
Design-system adoption with a small team. Start from an open design system, build the fintech primitives on top, and run with one or two designers plus a design engineer. Lower cost, strong consistency, less differentiation, and it only works if engineering owns the component library.
Decision matrix
| Criterion | In-house team | Agency or studio | Open design system plus small team |
|---|---|---|---|
| Time to first release | Slow (hiring first) | Fast | Fast |
| Cost over three years | High, predictable | Medium, lumpy | Low to medium |
| Arabic content depth | Strong if hired for | Usually weak | Depends on the one content hire |
| Response to regulatory change | Strong | Weak after handover | Medium |
| Cross-platform consistency | Strong with governance | Medium | Strong |
| Research continuity | Strong | None | Light |
| Product differentiation | High | Medium | Low to medium |
| Best for | Licensed products with a multi-year roadmap | Launch sprints, brand, specialist work | Pre-licence stage, B2B and embedded finance |
How I would decide
Before the licence, adopt a system and keep the team small; spend the money on research with real users instead. At licence, hire the content designer and the product designer and start the in-house path, keeping the agency for brand and campaigns. Once the product has more than two transactional surfaces, add the design engineer and treat the component library as production software. Revisit the decision whenever a new market or licence category appears.
Hire the person who writes the Arabic before the person who draws the illustrations.
FAQ
Should an Arabic fintech app use Arabic-Indic or Western numerals?
Default to the convention your users already see on their money and bills, and offer a setting. In Egypt most digital products and statements use Western digits; in Saudi Arabia and parts of the Gulf, Arabic-Indic digits are common in official documents. Whatever the default, keep it consistent across the app, the SMS and the receipts, and let the formatter, not the translator, decide.
How much friction is right for a transfer confirmation?
Proportional to risk. A repeat payment to a known beneficiary within normal limits needs one clear review screen and a biometric confirmation. A first payment to a new beneficiary, a large amount or an unusual time deserves a scam warning, a short delay with a visible cancel and a second factor.
Is a passkey or biometric login enough, or do we still need OTP?
Where the regulator accepts device-bound credentials as a strong factor, passkeys and biometrics are a better primary factor than SMS OTP: faster, phishing-resistant and more accessible. Keep OTP as the fallback for device changes and users without biometrics, and design that screen properly.
Can we A/B test onboarding and consent screens?
Test layout, ordering, instructions and clarity of wording, and measure comprehension and completion. Do not test fee presentation, consent defaults or disclosure prominence for the variant that converts best. If an experiment would embarrass you in front of the regulator, it is a dark pattern with a dashboard.
What is the minimum accessibility bar for a fintech app in MENA?
WCAG 2.2 AA in both language variants, with particular attention to contrast, target size, screen-reader labels on every amount and control, no colour-only meaning, and the accessible-authentication criterion for OTP and CAPTCHA. Then go beyond the standard: large tap targets, short sentences, icons with labels, and support that accepts voice.
Key takeaways
- Fintech users arrive anxious; design for the stressed person on a mid-range phone, not the calm designer on a large monitor.
- Regulation is an input to the design, not an excuse for a bad form; most requirements map to a handful of reusable patterns.
- Trust is a set of concrete signals (licence, fees before the button, consistent balances, honest status) a product can audit itself against.
- Every error message answers three questions: what happened, did money move, what should I do now.
- Build the Amount component first; formatting, sign, tabular digits, bidi isolation and three-decimal currencies belong in one place.
- Arabic is the primary design language here, not a localisation step: write it first, isolate bidi runs, support both calendars.
- Friction is proportional to risk: pause and warn on new beneficiaries and large amounts, stay out of the way for routine bills.
- Never A/B test fees, consent or disclosure for conversion; test clarity and measure comprehension.
- Hire the Arabic content designer and the design engineer before the illustrator; adopt a design system early and go in-house once you have a licence.