Close the account. Sight the original documents, collect a wet signature from every qualifying owner, and turn an approved application into a working account — at the customer's premises, on a tablet.

Context

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.

OTP verification screen awaiting a code sent to the customer's registered mobile — The same OTP as everywhere else, doing a different job — it is not verifying who the customer is. It is proving the officer is standing in front of them.

OTP verification screen in the locked-out state after repeated failed attempts — And what happens when the proof fails — the shortcut has to be closed for the control to mean anything.

Field officer dashboard listing scheduled appointments and completed visits — What the officer sees — a day of appointments, each one a room they have to be in.

Team lead dashboard showing their own queue with a reassign control on each card — What the team lead sees — the same work, plus the authority to move it.

Team lead viewing another team's queue — Looking across the gap — cross-team visibility, because the failure it solves is cross-team.

Reassignment modal selecting an officer from the Cairo queue — Mohandessin is in Giza and closer to Cairo — the work follows the map, not the org chart.

Take action menu listing all six outcomes available to the field officer — One button became six — every way a visit can actually end, named and recordable.

In-app call screen connecting to the customer over the device SIM — The call, placed from inside the application — an ordinary phone call that leaves a record behind it.

Reschedule modal for moving an appointment to a new date — Rescheduling as a recorded event, not a gap in the timeline.

Call feedback modal recording the outcome of a call to the customer — Why nine days were nine days — the cause, captured at the moment it happens rather than reconstructed later.

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.

The physical layer

Capture is guided, not uploaded. A framed camera view for the signature and the original documents — the officer is photographing a physical artefact in a room, not selecting a file. Everything captured lands against the application immediately.

Application documents awaiting verification against the originals — The verification list — the officer holds the original beside the copy already on the system. Collection became confirmation.

Application documents for multiple signatories with captured signatures attached — Signatures captured against each named owner — physical and digital from the moment the pen leaves the paper.

Paper is allowed, deliberately. The officer can open the same system on a laptop before leaving and print the uploaded images. Comparing an original against a printed sheet is faster than scrolling a tablet, and it works where the signal doesn't. The paper is for comparison; the tablet is for recording. Pretending the field is fully digital would have produced a worse tool than admitting it isn't.

The AOF generates itself. The account opening form is produced from data already collected — English and Arabic — and printed. For a sole proprietor, as-is. For a company with three owners, the signature page repeats three times, one per owner. Each signs by hand. The bank keeps the paper with the form; the officer photographs the signed cards and uploads them. The signature exists physically and digitally, from the moment it's made.

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.

Generated form page carrying ownership details for the second and third shareholders — Where the multi-partner constraint lands on paper — the page repeats once per owner, and each one signs their own.

Generated form page carrying the terms and digital consent declaration — The consent the customer read on screen, printed in the language they read it in — the accessibility argument, carried through to the paper.

The constraint the whole case file opened with

The reason Egypt could not reuse the UAE journey was, in part, multiple partners: every qualifying owner must sign in ink, and they are not always in the same place.

Here is how that closes.

All owners present is the fast path — one visit, all signatures, done. When they aren't, the officer proceeds anyway: signatures are taken from whoever is there, and the application stays pending while the officer travels to the remaining owner separately to collect theirs.

A partial visit is a valid visit. The alternative — declaring the trip failed and rescheduling everyone — would have punished the customer for a coordination problem that isn't theirs, and it would have made the six-branch constraint worse rather than better.

Application details showing multiple partners, each with their own verification state — Every owner tracked separately — which is what lets a visit be partial without being failed.

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].