The first foreign exchange app in a branch-first market

Buying dollars in Iraq, at the time we built this, meant going to a branch. The customer queued, took the rate on the board, and carried the cash out. Zain Islamic Bank wanted that service in its customers' hands, as an application. The part worth writing about is that the application could not finish the transaction.

Cash is physical. Somebody has to hand over notes and somebody has to verify who is receiving them. What software could remove was the queue, the uncertainty about the rate, and the wasted trip to a branch that has run out of the right denominations. So the product lets a customer buy USD, book a collection slot and open an account, with an administrative console where bank staff action each request. It was the first foreign exchange application in the Iraqi market, shipped as native Android and iOS clients against one shared services layer.

The state machine has a physical step in it

A purely digital purchase has a short lifecycle: requested, authorised, settled. Put a counter visit in the middle and the lifecycle grows a set of states that exist only because a person has to be somewhere at a particular time. Requested. Priced. Reserved against branch stock. Ready for collection. Collected. Expired.

Expired is the state that carries the design. A customer who does not turn up leaves the bank holding a reserved amount at a rate agreed earlier. That is an exposure with a clock on it, and the rules governing it are a treasury decision rather than a product decision. Having that conversation early changed what we built. The slot became a hold with an expiry the customer can see, and the release path runs automatically instead of waiting for somebody to remember a manual clean-up.

A slot is a branch capacity model

The obvious implementation of slot booking is a calendar widget. The correct one is a model of what a branch can actually do in an hour, which depends on tellers on shift, cash held in the right denominations, and whatever else is queuing in the lobby that morning. Offering a slot the branch cannot honour is worse than offering no slots at all, because the customer has now made a journey on the strength of it.

Capacity is therefore configured per branch, by the people who work there, and it changes week to week. The screen for setting it is unglamorous and nobody will ever demo it. It is also the piece that determines whether the product works.

The back office is the real product

Customer-facing screens get the design attention because they are what everyone sees in a review. On this build, roughly half the engineering value sat in the administrator console: the queue of purchase requests, the fulfilment steps, the account opening applications waiting on document checks, and the reporting that tells a branch manager what is arriving tomorrow. If that console is bad, the app becomes a promise the bank cannot keep.

Both clients shipped in Arabic and English from the same services layer, which is a subject of its own and one we will come back to. The localisation work is rarely where teams expect the cost to be.

The general lesson has followed us into other markets. A digital channel is worth building where a physical step remains, as long as the software is honest about that step existing and models it properly. The failure mode is a product designed as though the journey ends at the confirmation screen. The branch then improvises, and the customer discovers the improvisation.