Mox didn’t win because they hired better designers. They won because they had no legacy to fight.
This is the upstream constraint pattern, and it shows up in almost every significant digital or AI transformation in financial services once you learn to see it. The bottleneck is almost always upstream of where the pain is felt.
Mox is the cleanest case study because clean-slate versus legacy is essentially the only variable. Standard Chartered, PCCW, and Trip.com gave them distribution and a credible customer acquisition path. The mobile-first constraint was chosen, not inherited. The result is a product that can actually do things — instant cashback, real-time spending categorisation, in-app investment — that larger incumbents have wanted to offer for years and couldn’t, not because they lacked the engineering talent or the budget, but because their core banking systems couldn’t emit the real-time events that these features depend on.
The constraint wasn’t the interface. It was what fed the interface.
The same pattern appears in AI transformation, usually about six weeks into a deployment. A bank approves a GenAI initiative for something like real-time customer communication personalisation. The model is capable. The product vision is sound. Then the team discovers that the customer data is in three systems with different schemas, two of which require a change request process to query, and none of which emit events in real time. The AI product they envisioned requires an event streaming infrastructure that doesn’t exist. The infrastructure requires a core banking modernisation project that will take years.
The AI wasn’t the bottleneck. The core was.
This happens in process automation too. A bank deploys RPA on an approval workflow to reduce cycle time. The automation works; the workflow now moves faster. But the workflow was slow because each step required manual verification against data that was out of sync across systems. The automation does the same verification, just faster. Cycle time improves. The underlying problem — the data synchronisation gap — is unchanged and now more visible, because the automation exposes how much time each manual verification step was actually taking.
RPA on a broken process automates the chaos. It doesn’t fix it.
The consulting implication is specific: the first question in any AI or transformation engagement isn’t “what can we build?” It’s “what does the proposed solution actually depend on, and does that dependency exist in a form that will support it?” This question tends to produce a different conversation than the one most briefs invite. Briefs are written about the solution. The answer lives in the infrastructure.
Working backwards from the proposed solution to its dependencies — the data pipelines, the event streams, the API capabilities, the governance infrastructure — reveals what work actually needs to happen and in what sequence. Sometimes the sequence confirms the brief: the dependencies are mostly in place, and the solution can be built relatively directly. More often, the sequence reveals that the brief’s timeline is wrong, or that one or two platform investments need to happen first, or that the use case that looked most appealing is actually the hardest because its dependencies are the least ready.
This isn’t pessimism. Most of the infrastructure gaps in financial services are fixable. The issue is that they’re fixable on a different timescale than the AI deployment, and pretending otherwise produces projects that stall and stakeholders who learn the wrong lesson about what failed.
The firms that are executing well on AI transformation have, in most cases, accepted a less exciting narrative: we are building the foundation, and the impressive applications will follow. Mox is impressive not because its design team was talented, though it was. It’s impressive because it was built on an infrastructure that could actually support the product. The clean-slate advantage is real, and not available to incumbents. But the response to the clean-slate advantage isn’t to pretend the legacy doesn’t constrain you. It’s to fix what needs fixing, in the right sequence, with honest timelines.
The lesson from Mox isn’t “build a neobank.” It’s “know what your product actually needs, and fix what prevents it from having that.”
P.S. A useful framing exercise before any transformation initiative: take the intended end state and ask “what would need to be true about our infrastructure for this to be possible?” Map the gaps between that list and current state. That map is the real project — and it’s usually more useful than the strategy deck that preceded it.