The bank already had a digital acquisition journey in the UAE and wanted the same journey in Egypt. The leadership reversed that early (Egypt needed something built for Egypt) and brought me in to do it.
What began as a language decision turned out to be an architectural one. The UAE journey closes identity verification inside the app: Emirates ID with an NFC chip, UAE Pass, liveness check, federal face recognition, trade licences verifiable against a live registry.
Egypt has none of that. Banks have no verification API for the national ID. The commercial register cannot be checked online. The Central Bank requires that original documents be sighted in person and that every qualifying partner signs in wet ink.
So the journey could not end where the UAE journey ends. Translating the screens would have produced a form that collects data and then stops.
I designed six connected systems that carry an application as far as digital can take it, then hand it to a human deliberately, with every document already captured, every check already run, and nothing left to re-key.
4 Chapter
My role
Sole designer. I designed all six systems from scratch: customer onboarding, the bank-side application workflow, the customer portal, fulfilment and the account opening form, and the notification layer.
I ran the journey mapping workshop that established what actually happens when a business opens an account in Egypt. I proposed the service model where a bank officer travels to the customer with a tablet rather than the customer travelling to a branch. I proposed the customer portal as a system, and designed the architecture that connects the six.
I worked with a Product Owner, a proxy Product Owner, a Product Manager, and the compliance, governance, account opening and technical architecture teams. The engineering team and the executive stakeholders sat with me in Dubai; the Egypt business team, the Product Owner and the Customer Experience Group were in Cairo.
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.
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.
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.
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.
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.
Next chapter: Application Workflow — the same application, seen from inside the bank.
This is the journey most portfolios never show, because nobody outside the bank ever sees it.
Under the paper model, an application arrived as a folder. Governance read it, checked it, and typed it into Flex by hand. Name screening happened in a separate system that produced a PDF report. Mandates were built in another system again. Anything unclear — a blurred document, a missing page, a question about a partner — left the process entirely and became a phone call or an email to the Relationship Manager.
So the work was distributed across three systems and an unrecorded conversation. Every handoff was a place where time was lost and nothing was written down.
The unit doing this work is the Account Opening Unit, and inside it two roles matter: governance reviews the application, its documents, its mandates, and takes the decision; compliance works the name-screening results. Maker and checker are different people — the person who assesses is not the person who approves. That separation is the reason the rest of the design can be as fast as it is.
Decision
Fold the separate systems in, and give the exception a life
Two systems came inside. Name screening and mandates both moved into the workflow rather than staying alongside it. The point is not consolidation for its own sake — it is that the officer never leaves. Assessment, evidence, and decision now sit in one place, and the round trips that were consuming the turnaround time disappear.
Where the bank's other systems are still needed — deeper fraud investigation, verifying a compliance concern — those stay outside, deliberately. They are not part of the application's normal path, and pretending otherwise would have made the workflow pretend to be something it isn't.
The exception became an object. This is the part I care most about.
In the paper process, a query was an interruption. In this system, an exception is a structured record: a classified reason, the stage it was raised at, a status, who commented, when — and, critically, which specific artefact it points at.
That precision is the whole point. A national ID for the second partner uploads with a clear front and an unreadable back. OCR reads the front; the customer confirms it. But the back is unusable. The exception is not "document rejected" — it is a targeted request for one side of one document belonging to one named partner. The replacement lands in place. The old file moves to the archive, and at fulfilment the officer sees only the current version.
Without the classification, the system would not know what to replace with what. The category isn't reporting metadata — it's the address of the replacement.
And this is what closes the loop across the three systems: exceptions and Need customer clarification both surface in the customer portal as a question the customer answers. The invisible phone call became a channel with a record.
The five outcomes were already real. Approve, reject, need customer clarification, refer to compliance, refer to fraud — all five existed in the paper process. I did not invent them; I made them explicit as actions with structured reasons attached.
Referral is worth naming precisely: the application doesn't move. It stays exactly where it is. What changes is that a specialist with different permissions opens it — the only person who can record that a subject is not a fraud risk after checking systems this workflow cannot see. The referral transfers responsibility, not the file.
Result · The turnaround the customer experiences — twenty-four hours to three days from submission to an active account — is not a promise made on the customer's screen. It is a property of this system: nothing is re-keyed, nothing leaves the workflow, and every open question has a channel and a record.
And the workflow measures itself. Risk level, turnaround time and status sit on the dashboard; the audit log times every handoff to the second. The service level is observable rather than asserted — which is what makes it a service level at all.
Next chapter: Customer Portal & Notifications — the same application, seen by the person waiting.
This chapter is the other side of the previous one. An exception is raised inside the Application Workflow by a bank officer; it is lived here, by the customer.
Under the paper model, that exchange was a phone call. Governance found something unclear — a blurred document, a missing page, a question about a partner — and called the Relationship Manager, who called the customer. Nothing about it was recorded, its quality depended entirely on who made the call, and the customer had no idea any of it was happening.
The digital journey removes that call. And it removes something else: the customer's ability to ask "where is my application?" In a branch there is a person to ask. On a screen there is nothing, unless it is built.
So the portal is not a status page. It is the channel that replaces the phone call, plus the answer to a question nobody can otherwise ask.
Decision
Identity is the application, not an account
There is no registration, and no password. Nothing for the customer to create, remember, or lose.
The customer returns with either their application number, or the same email and mobile they started with, and verifies by OTP. From there the system decides where they belong:
There is one entrance and a state behind it. The customer is never asked to know the difference between continue my application and track my application — the system knows where they are and takes them there.
This is also what makes returning possible at all. Seven of ten tested participants paused and came back in a later session. They can, because identity is attached to the application rather than to an account someone has to maintain. Save-and-resume isn't a feature bolted onto the journey; it's a consequence of that decision.
The application number is repeated across several onboarding screens on purpose — it needs to reach the customer before they know they need it. And language can be switched before entry, not after.
Decision
The query is a conversation, not a rejection
One screen, three tabs: the application overview, pending queries, resolved queries — with counts on the tabs themselves, so the customer sees whether anything is waiting on them before clicking anything.
The status rail runs the full length of the process — submitted, document check, application review, account number generation, fulfilment, activation — with real dates against completed stages. The customer can see the whole road, including the parts that haven't happened yet. Where something is waiting on them, a banner sits above it with a direct way in.
Each query is a ticket: a number, a timestamp, a status, the request in the customer's own language, acceptance criteria, an upload area, and a free-text reply.
Three things about it matter.
The wording is generated from the exception type, not typed by the officer. When governance raises an exception for a tax card, the customer receives the same phrasing they saw when the document was first requested during onboarding. The customer doesn't learn a second vocabulary in order to fix something. The officer's free-text detail is appended to that fixed line — context added, never a substitute for it. This is the difference between a channel with guaranteed quality and a phone call whose usefulness depended on who made it.
Acceptance criteria come from the system, attached to the document type. What makes a valid tax card is not something the officer has to remember to write. This is a direct answer to a failure from the customer journey — commercial registers uploaded as a single first page, because nothing told the customer what "complete" looked like before they tried.
And where no document exists, the query is still a query. Several exception types ask for explanation rather than a file — the nature of the business, whether buyers are also shareholders, why there are no suppliers. Those are answered in text.
Decision
Resolved means the customer is done, not the bank
A ticket moves from Pending action to Resolved when the customer submits their response — not when the bank accepts it.
That is deliberate. If the status tracked the bank's internal review, a customer who had done everything asked of them would still be staring at Pending action, with no way to tell whether they had failed or were simply waiting. The status answers the only question the customer can act on: is anything waiting on me?
If the answer turns out to be insufficient — the tax card uploaded front-side only — the same ticket returns to Pending action with a follow-up. Not a new exception. One question, tracked across however many turns it takes, so the customer sees a conversation rather than an accumulating list of apparent failures.
And the same record is shown two ways. The customer sees a thread. The officer sees a table — the exception trail from the previous chapter. Same data, opposite presentation, because the officer is scanning dozens of applications a day and needs density, while the customer has one application and needs a story. Deciding that these are two different products rather than one shared screen is the whole design.
Result · No problems have surfaced in the portal or the emails — through testing, and through the controlled release. Tracking has been understood, and notifications have arrived.
That is a real result and a limited one. Egypt is in friends-and-family release; a channel like this is tested by volume, by customers who ignore email, and by queries that take four turns instead of one. None of that has happened yet.
What can be said is narrower and still worth saying: the phone call became a channel with a record, and the customer stopped waiting in the dark.
Next chapter: Fulfilment & AOF — the officer travels to the customer, and the account finally opens.
This is where the whole design meets its limit.
Egypt has no verifiable digital identity for banks. The Central Bank requires that original documents be seen in person and that every qualifying partner signs in ink. Mashreq has six branches in the entire country authorised to perform that verification. The journey was always going to end with a human in a room — the question was only who travels, and what they carry.
The bank decided that a dedicated fulfilment team would exist. That was a business decision, not my proposal. What I designed was the work.
And the work had changed shape. Under the old model, a Relationship Manager visited the company, took the partners' ID cards, and photographed them himself — he was collecting the data. Now the customer has already uploaded those images during onboarding. So the officer's job is to hold the original next to the copy on the system and confirm they match. The role moved from collection to verification — and that is a different job, with different tools and a different rhythm.
Existing staff moved into the team, and new people were hired, because the volume was expected to rise: a customer who could not reach a branch can now apply from anywhere, and someone has to go and see them.
Decision
The OTP proves the meeting, not the customer
The officer is standing in front of the customer. Identity is not in question.
But something else is. An officer could mark a visit complete without having made it — and the entire compliance chain behind the account would rest on that claim.
So fulfilment begins by sending an OTP to the customer's registered mobile, not the officer's. The customer reads it out; the officer enters it; the application opens.
Same mechanism as everywhere else in the journey, doing a completely different job. Here the OTP is not identity verification — it is proof that the meeting happened.
This is the piece of the system I would point to first if asked what regulated design means. It isn't protecting the bank from the customer. It's protecting the bank's own compliance record from the possibility of a shortcut.
Decision
Two dashboards, because a field team has a hierarchy
An officer sees scheduled appointments and completed visits. A team lead sees their own queue, completed applications, other teams' queues, and a Reassign control on every card.
Reassignment exists for two reasons, both from the ground rather than the org chart.
Absence compounds. The assigned officer is out. So is their team lead. Without a way across that gap, an approved account waits on a person who isn't there — so a lead from a different team can pull the application into theirs. The permission is deliberately cross-team, because the failure it solves is cross-team.
Administrative geography isn't real geography. Mohandessin sits in Giza governorate and is closer to Cairo. The Cairo team can serve it. The system lets the work follow the map rather than the org structure.
Every card carries its own outcome — completed, failed, rejected, successful — with where it happened attached: at the customer's premises, or at a Mashreq branch.
Decision
One button became a menu, because visits fail
MVP-1 had a single action: Proceed to fulfilment. It assumed the visit works.
Visits don't always work. Customers aren't there. Addresses are wrong. People ask to move the appointment. With one button, all of that collapsed into an application sitting still for no recorded reason.
So the button became Take action, opening: contact the customer · proceed to fulfilment · ask to reschedule · customer did not show · reject · and refer back to governance with a two-day window. The officer can call from inside the application — it places an ordinary call on the device's SIM — and record call feedback afterwards.
Two things came out of that, and the second is the one that matters.
It takes the blame off the officer. A delayed application now carries its cause. The officer did their job; the customer didn't show.
And it makes turnaround time explainable. Not just this took nine days but this took nine days because the customer didn't show once and rescheduled twice. The audit history records every state — assigned, pending, rescheduled, rejected — with a written reason.
This is the same principle as the workflow chapter, applied to time instead of judgement: you don't prevent the failure, you make it attributable. An operations team can act on that. They cannot act on an application that is simply late.
Result · The account becomes active when governance approves it. It becomes transactional only when the originals have been sighted and every qualifying owner has signed. This chapter is the distance between those two words, and closing it is what makes the twenty-four-hour to three-day figure a real service level rather than a claim about a database record.
The design never tried to remove the human from this step. Egyptian regulation puts one there, and no interface argues with that. What it did was make sure that by the time the human arrives, everything that could be done without them already has been — documents captured, data verified, form generated, nothing left to collect and nothing to re-key.
The officer arrives to confirm, not to gather. That is the whole point of the six systems behind them.
This completes the Egypt Acquisition (Web) case file. See also: [Accessibility — Bilingual, RTL & Regulatory Comprehension], and the sibling case file [Neobiz Mobile — Egypt].
AchievedTimed across ten prototype-testing sessions and documented
24 hours – 3 days to an active account
Not measurableThe service level agreed with the business, achievable because no data is re-keyed — an agreed target, not yet measured against a commercial launch
Half of tested participants began in English; nearly all switched to Arabic at the regulatory step
AchievedTen prototype-testing sessions
The same language-switching behaviour after go-live
AchievedReported by the analytics team; not a figure I measured myself
1,500+ new SME accounts in year one
Not measurableA declared business target. Egypt is in controlled release; there has been no commercial launch, so nothing exists yet to measure it against
~30% recovery of applicants who had abandoned the branch route
Not measurableA declared target from controlled release, not a conversion increase — no commercial launch has happened yet to measure it against