Objective

Chapter 1 of 4

Take a business account application from a first-time visitor to a submitted, verified, machine-readable file — without a bank officer sitting beside the customer, and without anyone re-typing a single field afterwards.

Context

In an Egyptian branch, opening a business account looks like this. The customer loses a day. They take a number, wait, reach an officer, and say they want to open an account. The officer asks for the commercial register and the tax card — and often the customer has brought the wrong papers, so they come back another day. The officer works through the company's activity, its partners, its suppliers and importers, its expected annual turnover. Then the regulatory section: FATCA, sanctions, politically exposed persons.

Here is the part that mattered most.

The officer asks those regulatory questions out loud, in plain Arabic, and answers them on the customer's behalf. Do you deal with these countries? Do you have relatives in politics? Do you hold a green card, or pay tax in America? The customer says no, no, no. The officer fills the form. The customer signs — usually without reading it.

Paper account opening form, regulatory declaration page covering FATCA and politically exposed persons — The page the officer fills on the customer's behalf. Every question here is one the customer answers out loud and signs without reading.

If the company has multiple partners, either every partner comes to the branch with original identity documents for wet signatures, or a Relationship Manager travels to the company to collect them. Either way, another day. Then governance reviews everything and re-keys it by hand into Flex, the core banking system. Every field written in ink is typed again by a person.

Two weeks to a month, sometimes longer.

Cover page of the generated account opening form — The form the customer used to fill by hand, now generated from data they already gave — the same eighteen pages, none of them re-typed.

The digital journey removes the officer. That is the whole design problem — and it is not a saving. The officer was doing invisible work: interpreting, judging what was needed, and guaranteeing the form came out complete. Every problem I hit in this journey traces back to that missing person.

FATCA declaration rendered in Arabic, right-to-left, with the stepper and guidance rail mirrored — What the argument won — the regulatory section in Arabic, mirrored structurally rather than translated over an English skeleton.

Decision

The language fight

What I proposed first: Arabic-first. If we were building for Egypt rather than translating for it, Arabic should be the source of truth and English the derivative. Rejected. Not on evidence — on governance. The decision-makers sat in Dubai and were not Egyptian. They could not read what they were being asked to approve. We can't understand Arabic. Build it in English, we'll approve it, and Arabic comes in phase two. What I proposed second: switch language anywhere in the journey. If the customer can't have Arabic by default, let them reach for it at any moment. Rejected too, and this time the objection was real. Free-text answers would have to be matched across two languages — a customer answering in Arabic, the system expecting English. Over-development for a marginal gain, and the architects were right. Where I went instead. I stopped arguing for the whole journey and looked for the one place the technical objection didn't hold. It didn't hold at the regulatory section. FATCA answers are required in English regardless of interface language — the form goes to a foreign authority, in the customer's own words, not in translation. Most of the section is yes/no, which translates without ambiguity. So at exactly the step where comprehension carries legal consequence, there was no matching problem to solve. I made two arguments in the room. The first was market knowledge: Egyptians who run their businesses in English still switch to Arabic at the ATM and at the bank counter — the moments where money and legal consequence are on the line. The second reframed the question entirely. This is not a language preference. It is accessibility and informed consent — a customer has the right to read, in their own language, what they are about to sign. In a branch, a human provided that. Removing the human does not remove the obligation. That argument won. The customer can switch between Arabic and English inside the regulatory section without losing their place — and in both directions, which matters for the foreign resident who handles everyday Arabic but wants sanctions questions in English. Then the testing agreed with me. Half the participants began in English. Nearly all of them switched to Arabic at exactly that step. The same behaviour was reported again after the controlled release. And I lost Arabic-first permanently — correctly, I now think. What shipped is a language choice on the first screen that carries through the whole application. It mirrors what actually happens at a branch: you walk in and ask for someone who speaks Arabic, or someone who speaks English. The customer portal is the exception, and deliberately so — it is an open conversation rather than a structured form, so either language works and bank staff handle both.

Evidence

A screening survey went to more than twenty SME owners, asking about language preference and what they knew about regulatory terminology. It shaped the questions rather than the design, and the instrument itself is no longer in my hands — so nothing in this case file rests on it.

Ten discovery interviews and, later, ten prototype-testing sessions with Egyptian business owners: sole traders and partnerships, existing Mashreq customers and prospects.

What the testing found, in participants rather than percentages:

Finding	Count
Did not understand FATCA / PEP terminology	8 of 10
Felt overwhelmed by the regulatory declaration screens	6 of 10
Paused and returned in a later session	7 of 10
Had real working knowledge of the regulatory terms	about 2 of 10
Began in English	5 of 10 — nearly all switched to Arabic at the regulatory step

Almost all of them already held accounts at several banks. The gap was never financial literacy. They had answered these questions before — out loud, to a person who translated them.

The regulatory section was the only thing all ten participants complained about.

FATCA declaration screen in English, as first encountered — The screen every participant complained about — eight of ten could not define the terms it asks them to certify.

What I designed

Language switching inside the regulatory section, in both directions, without losing position.

A staged journey that mirrors the branch conversation — company details, ownership and signatories, financial details, regulatory declaration, review and submit. Each stage is cognitively bounded so the decisions arrive in the order a person can hold them.

Ownership dashboard listing every Key Individual as a separate card — The ownership dashboard — every Key Individual added, each a card with its own document state.

The regulatory section placed last, on purpose. I could have put it first. I put it at the end because commitment accumulates: a customer who has already invested twenty minutes will push through a hard section, where the same section on screen two sends them away.

OCR on the commercial register and national ID, so structured data is extracted rather than typed — which is also what makes the twenty-four-hour activation possible, because governance is reviewing data rather than transcribing it.

Company details form with fields pre-filled from the uploaded commercial register — Company details, pre-filled from the uploaded commercial register — the customer confirms instead of typing.

Contextual guidance in place of the officer — plain-language explanation at the point of the question, not in a help centre.

Modal defining what a politically exposed person is, in plain language — The PEP definition, explained where the question is asked — the officer's spoken explanation, rebuilt as a modal.

Nine features carry the journey: signup · company documents and OCR · company mismatch handling · meetup preferences · partner dashboard · individual documents and OCR · financial preferences · bilingual regulatory declaration · review and edit.

Account plan selection screen with three tiers, Prime selected — Plan selection for the eligible applicant — three tiers, one screen.

Outcome screen for a non-eligible company, offering Relationship Manager assistance — The deliberate rejection path — a non-eligible company is handed to a Relationship Manager, not to a dead end.

Key Individual form completed for a non-Egyptian, non-resident partner — One cell of the ownership matrix — a non-Egyptian, non-resident partner, with the fields that case actually requires.

FATCA declaration branch for a passive non-financial entity with a US-person beneficial owner and SSN field — The deepest FATCA branch — passive non-financial entity, US persons, UBO with SSN — designed so only the customers it applies to ever see it.

The interface

The same FATCA declaration, in both languages. Not a translation layer over an English skeleton — the stepper reverses, the guidance rail moves to the right, the navigation flips, the whole composition mirrors. Building this is why I asked for RTL support in the bank's shared design system in my first year, rather than hand-flipping components screen by screen. Note what stays in English: the declaration answers themselves. That constraint is exactly what made the language switch cheap enough to win.

The decision, in one screen. A regulatory term the customer has never had to understand alone — because a branch officer always explained it — with the explanation available in either language, switched in place. This is what I argued for after losing Arabic-first and losing switch-anywhere: not the whole journey, but the moment where comprehension carries legal consequence.

Company details, pre-filled from the uploaded documents. The customer confirms rather than types. This is also the reason activation takes days instead of weeks — governance reviews this data rather than re-keying it into Flex.

Review, collapsed. The five stages held as separate, editable sections rather than one long form — the structure that lets a customer leave and come back, which seven of ten did.

All interface work is shown as designed. Figures and identifying data are sample values; the production visual skin is under NDA.

The fight I lost

I proposed gating the regulatory section. One filter question for FATCA — do you hold US citizenship or a green card, or pay US tax? One for sanctions. One for politically exposed persons. A "no" collapses that entire section. All three fit on one screen for the great majority of applicants.

Compliance and governance rejected it. I did not win that argument.

What happened afterwards is worth recording honestly. Compliance later returned and reduced the questions themselves, grouping related ones together. But the change was in the wording, not the count — five questions stayed five questions, phrased more clearly. Better, and less than what I asked for.

Sanctions declaration screen with all five questions answered — The sanctions declaration that shipped — five questions that stayed five, phrased more clearly than they began.

I would still make the same proposal today.

Result

An application that took two weeks to a month now takes about fifteen minutes to submit — measured across ten testing sessions.

More importantly, the data the customer enters is the data that reaches Flex. Nobody re-types it. That single property is what turns activation from a queue into a service level.

Submission confirmation screen with a company visit selected — The submission close — the customer chooses where the one remaining human meeting happens.

Branch selection list showing Mashreq branches — Or they come to the bank — the branch list, inside the same screen. The journey removes re-typing, not the human.

Next chapter: Application Workflow — the same application, seen from inside the bank.