Arabic-First Finance AI: Pairing Jais, Falcon and ALLAM With a Numbers Layer That Doesn't Hallucinate

Three years ago, asking a chat model to analyze an Arabic financial statement was a bad idea. The model would mangle the dialect, lose the right-to-left table structure, and treat Arabic as a translation detour. That objection is mostly gone. Arabic-first models (Jais from the UAE, Falcon from Abu Dhabi’s Technology Innovation Institute, ALLAM from Saudi Arabia’s SDAIA) were trained with Arabic as a primary language. For reading a board pack or summarizing a regulator’s circular in Arabic, they’re good.

Here’s the part that didn’t change: a better Arabic model does not make a model better at math. Those are unrelated skills, and conflating them is how CFOs get burned.

What the Arabic-first models actually fixed

The improvement is real and worth naming precisely. These models handle Modern Standard Arabic and several dialects, follow Arabic financial prose, and produce fluent Arabic narrative. If your problem is comprehension (what does this Arabic disclosure say, what’s the gist of this auditor’s note) an Arabic-centric LLM is now a reasonable tool.

The mistake is assuming comprehension extends to computation. It doesn’t, and the reasons are specific to how finance is written in Arabic.

The traps that survive a great language model

Mixed Eastern and Western numerals

GCC documents routinely mix Eastern Arabic numerals (٠١٢٣٤٥٦٧٨٩) with Western digits (0123456789), sometimes in the same table. A model that reads the Arabic flawlessly can still normalize ٤٢ inconsistently (treating it correctly in one cell and dropping it in another) because numeral handling is a tokenization artifact, not a reasoning step it performs deliberately.

Decimal and thousands separators

Arabic has its own decimal separator (٫) and thousands separator (٬), and GCC reporting also uses Western commas and periods. The same string of characters can mean 7.5 or 75 depending on which convention applies. We’ve seen a model read ٧٫٥ as seventy-five. One misread separator and a margin, a covenant ratio, or a tax base is off by an order of magnitude.

IFRS and AAOIFI code-switching

A Gulf group often reports its conventional entities under IFRS and its Islamic finance operations under AAOIFI standards. The Arabic term can be the same while the accounting treatment differs: revenue recognition on a murabaha versus a conventional loan, for instance. An LLM holding the framework rule only in its prompt context will drift between conversations. The treatment has to live somewhere stable.

Right-to-left table reconstruction

When a model rebuilds a table from extracted text, it can transpose columns it never saw laid out visually. In a right-to-left document, that risk compounds. A transposed column quietly swaps your current and prior period.

None of these are flaws in the language model’s Arabic. They’re numeric and structural problems wearing Arabic clothing, and a more fluent model doesn’t touch any of them.

Why the fix is a separate layer, not a better prompt

You can prompt-engineer around a separator bug for one document. You cannot prompt-engineer determinism into a probabilistic system. An LLM generates the most likely next token; it does not execute arithmetic. Add Arabic numeral ambiguity and the odds of a clean computed answer get worse, not better.

So the answer isn’t to pick the best Arabic model and trust its math. It’s to let the Arabic model do language and put a deterministic numbers layer underneath to do everything numeric. That’s the whole premise of our pillar: the reliable financial-modeling layer for AI.

Concretely, here is the division of labor we build:

• Ingestion normalizes once. When we connect your accounting platform or statements, Eastern and Western numerals are converted to one canonical form, separators are resolved against the document’s actual convention, and the figures are reconciled so the model ties out to the ledger.
• The math runs in code. Scenarios, ratios, and rollups go through a deterministic engine, not the LLM. Ask the same question twice and you get the same number twice.
• Framework rules are stored, not prompted. IFRS and AAOIFI treatments are encoded in the model, so the Islamic-finance line is handled consistently across every query, not re-guessed each session.
• Every figure traces to source. The answer the Arabic model writes is backed by a chain to the ledger line an auditor can follow.

The Arabic-first LLM is the right interface for this. It understands the Arabic question and explains the Arabic answer. It is the wrong component to be the number.

The honest limit

This pairing doesn’t make the language model perfect, and it shouldn’t pretend to. If your source document is genuinely ambiguous (a scanned report where ٧٫٥ and ٧٬٥ are visually indistinguishable) the layer surfaces the ambiguity rather than guessing. That’s the point. A deterministic system that flags “I cannot resolve this separator” is worth more to a CFO than a fluent one that confidently picks wrong. We’d rather show you the gap than paper over it.

For the surrounding context, see why GCC CFOs don’t trust AI with their numbers and how the same layer handles ZATCA, e-invoicing, and audit-ready models.

The takeaway is narrow and firm: choose the best Arabic model you can for language, then refuse to let it do arithmetic. Pair it with a reconciled, deterministic model and you get Arabic fluency without the order-of-magnitude surprises. If you want to test that on a real Arabic management report (mixed numerals and all), book a demo and bring the messiest statement you have.