Most banking assistants in the Middle East were designed in English and translated. The result is an assistant that handles “show my balance” and fails “وش باقي برصيدي” or a message that switches from Arabic to English halfway through, which is how a large share of Gulf customers actually write. Arabic is the first language of the majority of bank customers in the region, and the gap between how assistants perform in English and in Arabic is one of the main reasons adoption of chat channels at Gulf banks has lagged the investment in them.
This guide covers what Arabic-first means in practice: dialect and code-switching, right-to-left and bidirectional design, how to evaluate language models on real Arabic banking conversations, and the architecture for a bilingual assistant that keeps customer data inside the bank.
Why Arabic is hard for assistants
Modern Standard Arabic is what the model learned from most of its training text; it is not what customers type. Gulf, Levantine, Egyptian and Maghrebi dialects differ in vocabulary, grammar and even in how numbers and money are expressed, and within the Gulf a Saudi customer in Riyadh, a Kuwaiti and an Omani write differently. Customers also mix scripts and languages freely: Arabic words in Latin letters (Arabizi), English product names inside Arabic sentences, and numerals in either Eastern or Western forms. Add the morphology of Arabic, where a single token can carry a preposition, a noun and a possessive, and the retrieval and intent layers built for English quietly underperform.
The failure mode is not usually a wrong answer. It is a confident answer to a slightly different question, or a fallback to “I did not understand” that sends the customer to the call centre the assistant was meant to deflect.
What Arabic-first design requires
Dialect coverage decided deliberately: which dialects the assistant must handle well, tested with real messages from each market rather than with translated English test sets. Code-switching handled natively, so that a sentence with Arabic and English is understood as one sentence. Entity handling for names, amounts, dates and account identifiers across both numeral systems and both scripts. And tone: formal Arabic for confirmations and regulatory text, the customer’s own register for conversation, and consistent terminology with the bank’s app and contracts.
Right-to-left is more than mirroring. Mixed-direction strings, such as an Arabic sentence containing an English product name and an amount, need correct bidirectional rendering in the chat interface, in notifications and in anything the assistant generates for a document. Interfaces that were designed left-to-right and flipped at the end show their seams in exactly these cases.
Evaluating models on Arabic
Public benchmarks rank models on Modern Standard Arabic and translated tasks, which tells a bank little about Gulf dialect banking conversations. The useful evaluation is private and specific: a few thousand real, anonymised customer messages from the bank’s own channels, labelled by intent and by the correct action, run through each candidate model inside the bank’s retrieval and tooling setup, and scored on understanding, action accuracy, tone and refusal behaviour. Several open-weight models now perform well on Arabic when fine-tuned or prompted properly, and they can be deployed inside the bank’s infrastructure, which matters more than a small benchmark lead.
Evaluate continuously, not once. Dialect use, product names and fraud patterns in messages all drift, and a model that scored well at launch can degrade in practice without anyone noticing unless the evaluation runs on fresh data.
Architecture: bilingual, grounded, inside the boundary
The assistant should be grounded in the bank’s own content and data: product terms, policies, FAQs and the customer’s accounts, retrieved at run time and cited in the answer, so that it does not invent a fee or a rate. Retrieval must work across both languages, which usually means multilingual embeddings and a knowledge base maintained in Arabic and English rather than translated on the fly. Actions go through the same APIs and the same authentication the mobile app uses, with confirmation steps in the customer’s language.
Because customer data cannot leave the country under the data residency rules of Saudi Arabia, the UAE and their neighbours, the model and the retrieval stack run in a local cloud region or on the bank’s own infrastructure. Open-weight models with strong Arabic performance have made that practical; a bank no longer has to choose between residency and quality.
Measuring success
Measure containment honestly: the share of conversations resolved without a human, split by language. Measure action completion, not only answers given. Measure customer satisfaction per language and per dialect, and read the transcripts where Arabic customers switched to English or gave up, because that is where the next improvement lies. A bilingual assistant that performs equally in both languages is achievable; one that performs equally only on the dashboard is common.
How Eurisko helps
Eurisko is a bilingual company building banking software from Beirut for Arabic-speaking markets since 2009. Our Kortex assistant inside Eurisko DXP is designed Arabic-first: dialect-aware understanding, code-switching, native right-to-left interfaces, grounding in the bank’s content and deployment on open-weight models inside the bank’s data centre. If your assistant works in English and disappoints in Arabic, our AI team can show you the difference on your own conversations.
