A credit risk analyst in Riyadh needs to know how many SME loans in the Eastern Province moved into 30 days past due last quarter. She knows exactly what she wants. She can say it in Arabic in one sentence. What she cannot do is write the four-table join against the core banking warehouse, so she files a request with the BI team and waits three days for a spreadsheet that answers a slightly different question.

That gap shows up in almost every bank in the Gulf. The people closest to the business work in Arabic and English, often switching mid-sentence. The data lives in warehouses that only speak SQL. Dashboards cover the questions someone predicted last year, and everything else becomes a ticket. Arabic text-to-SQL closes that gap: an analyst asks a question in plain Arabic or English, and the system writes a governed SQL query, runs it against approved data, and returns the answer with the query shown for review.

Why standard text-to-SQL tools struggle with Arabic

Most natural language to SQL tools were built and tested on English questions and English schema names. Point them at a Gulf bank and they hit problems fast.

Arabic is morphologically rich. One root can produce dozens of word forms, with prefixes and suffixes attached. A model that matches keywords will miss that two differently written words refer to the same field.

Analysts mix languages. A real question often looks like an Arabic sentence with English product codes, branch names, or banking terms dropped in. Tools that expect one language per question get confused.

Dialect and formal Arabic both appear. Someone typing quickly in Jeddah or Dubai does not write the way a policy document does. The system has to understand both.

Schema names rarely match business language. The warehouse column might be called DPD_BKT_CD. The analyst says "متأخرات أكثر من ثلاثين يوم" or "over 30 days past due." Something has to connect the two, and generic tools do not know your bank's vocabulary.

Numbers, dates, and calendars vary. Questions can include Eastern Arabic numerals, Hijri references, or fiscal quarters that do not line up with calendar ones.

None of these are reasons to give up on the idea. They are reasons to build it for the language and the bank, rather than bolting a generic chatbot onto the warehouse.

What a production bilingual text-to-SQL system does

A useful system for banking is more than a model that guesses SQL. In practice it is a pipeline with clear steps.

Understands the question in either language. It normalises Arabic spelling variants, handles mixed Arabic and English, and resolves dialect phrasing into a clear intent.
Maps business terms to the semantic layer. A curated glossary links phrases like "past due," "متعثر," "active customer," and "retail book" to approved tables, columns, and definitions. This is where most of the accuracy comes from.
Generates SQL against approved views only. The model writes queries over a governed layer, not raw production tables, so joins, filters, and metric definitions stay consistent with finance and risk.
Checks the query before it runs. Read-only enforcement, row limits, cost checks, and rules that block sensitive columns unless the user's role allows them.
Applies row-level and column-level security. A branch manager sees their branch. A compliance officer sees what compliance is allowed to see. The system inherits the bank's existing access model rather than inventing a new one.
Answers in the language of the question. Results, a short explanation, and the generated SQL come back together, so analysts can check the logic and the BI team can reuse good queries.
Logs everything. Every question, query, user, and result set is recorded for audit, which matters for regulators and for improving the system week to week.

The goal is not to remove the data team. It is to let them stop writing the same variations of the same query and focus on the hard analysis.

Why in-region deployment is not optional

Banking data in Saudi Arabia, the UAE, and the wider Gulf sits under data residency rules and central bank guidance that make sending customer-level queries to an overseas API a hard sell. Security teams will ask where the model runs, where the prompts are stored, and who can see the results.

A bilingual text-to-SQL system for a Gulf bank should run in-region: on the bank's own infrastructure or a local cloud region the bank already approves. Models, embeddings, the semantic layer, and logs all stay inside that boundary. Only schema metadata and approved views reach the model, and customer-level data is returned to the user without leaving the bank's environment. That design is usually the difference between a pilot that gets signed off and one that stalls in security review.

Where Arabic text-to-SQL projects go wrong

Skipping the semantic layer. Pointing a model straight at hundreds of raw tables produces queries that look right and return wrong numbers. Start with a small set of governed views and a glossary the business agrees on.

Testing only in English. If the evaluation set is English questions, you will not find out how the system handles real Arabic phrasing until users complain. Build the test set from questions analysts actually asked, in the way they asked them.

Hiding the SQL. Analysts and auditors need to see what ran. A black box answer, even a correct one, will not be trusted for anything that reaches a credit committee.

Ignoring access controls. If the system can see everything, it will eventually show someone something they should not see. Inherit roles from the existing warehouse permissions from day one.

Trying to cover the whole bank at once. Retail, corporate, treasury, and risk all have different vocabularies. One domain done well beats five done badly.

A first slice a bank can defend

Pick one domain with frequent ad hoc questions and a clear owner. Retail lending, collections, and branch performance are common starting points.

Define 15 to 30 governed views and a bilingual glossary of the terms that domain uses every day
Collect 100 to 200 real questions from analysts in Arabic, English, and mixed form, with the correct SQL for each
Run the system read-only for a small group of analysts for four to six weeks, with every query logged and reviewed
Measure answer accuracy against the test set, time from question to answer, and how many BI tickets that domain stops generating

If accuracy holds and the security team is comfortable with the logs, widen to the next domain. If a class of questions keeps failing, fix the glossary or the views before adding more users.

How Genetex builds Arabic text-to-SQL for banks

Genetex AI builds private RAG, AI agents, Voice AI, and workflow automation for teams that need production systems, not demos. We have delivered a bilingual text-to-SQL system for a Saudi bank, where analysts ask questions in Arabic or English and get governed SQL over the core warehouse, deployed in-region with the bank's own access controls and full audit logging.

For a new bank engagement that usually means a semantic layer and bilingual glossary built with your data team, a query pipeline with read-only enforcement and role-based security, an evaluation set made from your analysts' real questions, and deployment inside your approved environment.

If your analysts still wait days for answers they could describe in one sentence, start with one domain, one governed set of views, and one group of users. Book a working session with Genetex and bring a sample of recent ad hoc data requests, in whatever language they were written, plus a rough map of the warehouse tables behind them.

Arabic text-to-SQL: how Gulf banks let analysts ask data questions in Arabic or English