Banking & Finance
Banking generates more contact per customer than almost any sector, and almost all of it is a small set of questions about balance, transactions, cards and eligibility. The volume is enormous; the tolerance for error is not.
Banking generates more contact per customer than almost any sector, and almost all of it is a small set of questions about balance, transactions, cards and eligibility. The volume is enormous; the tolerance for error is not.
What contact looks like in this sector
Financial services contact splits cleanly into two categories, and the split matters more than any other design decision. The first is informational — what are your rates, how do I apply, what documents do I need, where is my nearest branch. None of it is personal, none of it requires identity, and it is a very large share of total volume.
The second is account-specific — my balance, my transaction, my card, my application. Every one of these requires certainty about who is asking, and the consequence of getting that wrong is immediate and severe.
Deployments that treat these as one problem end up applying the strictest possible controls to questions about branch opening hours, which makes the assistant useless for the majority of contact. Deployments that separate them properly serve the informational half immediately and apply real verification only where it is genuinely needed.
Where an assistant helps most
Product and rate questions
Published rates, product features, eligibility criteria — high volume, no personal data, immediately answerable.
Application requirements
What documents are needed and in what form. Getting this right prevents the rejected application and the second visit.
Application status
Where a submission has reached, which is the largest source of repeat contact after an application is made.
Card issues
Lost, stolen, blocked, not working — where speed matters more than anything and the first thirty seconds decide the experience.
Transaction questions
"What is this charge" against the customer's own record, where the systems are connected and identity is established.
Branch and service questions
Locations, hours, what a branch can do — trivial, constant, and currently occupying trained staff.
The regulatory picture
Financial services carry the strictest regulatory posture of any commercial sector here, governed by the Personal Data Protection Law alongside sector rules from the Saudi Central Bank. The requirements that shape an assistant deployment are consistent: know where personal and financial data is processed, establish identity before disclosing anything account-specific, retain records appropriately, and be able to evidence what happened.
The line that matters most is between information and advice. Explaining how a product works, what it costs and who is eligible is information. Recommending that a particular customer take a particular product is advice, and financial advice is a regulated activity. An automated system should be configured so that it cannot cross that line, and the boundary should be written into the agent's limits rather than left to judgement.
Data residency is decisive here for the same reason as in government. A bank is expected to know where customer data is processed, and an assistant that sends personal or financial data outside the Kingdom introduces a question that has to be resolved before anything else proceeds.
Sector-specific requirements
| Identity before disclosure | Nothing account-specific without certainty about who is asking. This is the control that matters most and the one where convenience must not win. |
|---|---|
| Information, never advice | Product explanation is permitted; recommendation is a regulated activity. The boundary belongs in the agent's configured limits. |
| Data residency | Personal and financial data processed inside the Kingdom, with a clear answer to where it goes and who can reach it. |
| PII handling | Account numbers, national identity numbers and card details recognised and handled appropriately rather than repeated back into a transcript. |
| Auditability | A reviewable record of what was asked, what was disclosed and to whom — the evidence a complaint or a regulator will eventually require. |
| Fraud awareness | Alertness to social-engineering patterns, because an assistant is a new surface for exactly that and a helpful one is easier to manipulate than a suspicious human. |
| Escalation on hardship | Financial difficulty requires judgement and regulatory care, and belongs with a person immediately. |
A realistic rollout
- Separate the two contact typesInformational and account-specific. The first can go live quickly and covers most volume; the second needs identity infrastructure and takes longer.
- Start with informationRates, products, requirements, branches. No personal data, immediate value, and it builds internal confidence for the harder half.
- Settle identity properlyUse the bank's existing authentication rather than building verification inside a conversation. Shortcuts here are the ones that become incidents.
- Write the advice boundary downPrecisely what the assistant may say about products, agreed with compliance before launch rather than discovered after.
- Rehearse fraud scenariosDeliberately attempt to manipulate the assistant during testing. It is the sector where someone certainly will.
- Add account access lastOnce identity, audit and escalation are proven on the informational half.
What makes this sector different
What distinguishes banking is that the assistant becomes part of the fraud surface the moment it can access account information. A helpful system is, by design, easier to socially engineer than a trained and suspicious human, and attackers will test it specifically because it is new.
The defences are structural rather than conversational. Identity established through the bank's own authentication rather than through questions in a chat. Disclosure limited to what that verified identity permits. No mechanism by which persuasion, urgency or authority claimed in a message can widen access. And a record of what was disclosed, so that anything unusual can be found afterwards.
The second distinguishing feature is that customers in financial difficulty are a protected category in practice as well as in principle. Automated handling of hardship is both ineffective and potentially non-compliant, and the assistant should be configured to route it to a person immediately rather than to attempt reassurance.
Questions to settle before you start
Which half first?
Informational contact can go live quickly. Account access requires identity infrastructure and should follow.
Where does identity come from?
The bank's own authentication. Verification built inside a conversation is the weak point attackers look for.
What is the advice boundary?
Written with compliance, before launch, into the agent's limits.
How is hardship handled?
Straight to a person. This should be explicit rather than a judgement call at runtime.
What is recorded?
Enough to evidence a disclosure, retained appropriately, reachable when a complaint arrives.
Who owns product accuracy?
Rates and terms change. Somebody must be accountable for the assistant reflecting the current ones.
Building the business case
The case for an assistant in this sector is usually made badly, and the reason is that it is presented as a cost saving. Cost savings invite scrutiny of headcount, which makes the project political before it is technical, and they are also the hardest benefit to evidence because the people whose time is freed do not disappear — they do other work.
The stronger case is capacity and coverage. Contact that currently waits is answered immediately. Hours that were never staffed are covered. Questions that quietly went unanswered — because someone gave up rather than call — get answered. None of those require anyone to lose a job, and all of them are measurable if you take a baseline first.
That baseline is the part most organisations skip and later regret. A month of contact volume, categorised and timed, costs a day of someone's attention and turns every later claim from an assertion into a measurement. Without it, the conversation six months after launch is about impressions rather than evidence, and impressions are shaped by whoever complains loudest.
The second thing worth quantifying early is the cost of the current failure mode. In most organisations a meaningful share of contact is abandoned — the caller hung up, the visitor closed the chat, the applicant never came back. That is invisible in every report because nothing was logged, and it is frequently larger than the volume that was handled.
How this typically goes wrong
Launching across everything at once
Broad deployments produce mediocre answers everywhere and lose internal trust at the first confident mistake. Narrow ones that answer a few things extremely well earn the right to expand.
Treating governance as paperwork
Consent, retention and audit decided late are the most common reason a working pilot never reaches production. They are cheap to design in and expensive to retrofit.
Measuring containment alone
It improves when escalation is made difficult. A rising containment figure alongside rising repeat contact means problems are being deferred, not solved.
Using marketing content as the knowledge base
People ask about policies, procedures and exceptions. Those answers live in operational documents, not on the brochure page.
Leaving Arabic to translation
A translated experience is visibly poorer, and in this market that is noticed immediately and read as a statement about who the service was built for.
No named owner
Assistants without an owner go stale at a predictable rate, and the decay is invisible until a customer quotes something outdated back to you.
What to expect
Bilingual service is not optional here
Financial terminology is where bilingual assistants most often fail in this sector, and the failures are subtle enough to survive testing. Arabic financial vocabulary is precise and, in Islamic finance particularly, terms carry specific meanings that do not survive casual translation. A system that renders a product name approximately has misdescribed a financial product, which is a compliance problem rather than a language one.
Numerals compound it. Arabic text mixes Eastern and Western numeral forms, currency placement differs, and dates appear in both Gregorian and Hijri form depending on context. Getting these wrong in a balance or a due date is immediately visible and undermines confidence in every other figure the assistant produces.
The practical answer is to have the Arabic material reviewed by someone who works in the sector in Arabic, rather than by a translator. The distinction matters: a translator produces correct Arabic; a practitioner produces correct financial Arabic, and those are different outputs.
Common questions
Where identity is established through your own authentication and the systems are connected. Never on the basis of information supplied inside the conversation alone.
No. It explains products, rates and eligibility criteria. Recommending is financial advice, which is a regulated activity, and the boundary is written into the agent's limits.
The assistant is a new surface and should be treated as one. Disclosure is bounded by verified identity, and no amount of urgency or claimed authority inside a conversation widens it.
Inside the Kingdom. For a bank this is normally a threshold question rather than a preference.
Routed to a person immediately. Automated handling of financial difficulty is ineffective and, depending on the product, potentially non-compliant.
It must, and this is worth reviewing with a practitioner rather than a translator. Approximate rendering of a product name is a compliance issue, not a wording preference.
See it against your own material
A working assistant on your own content, in both languages.