Digital banking, the licence is the easy part
Mauritius has published a clear route to a digital banking licence. The capital is a number and the timeline is a number. The hard part starts the day after authorisation, and it fails quietly.
The Bank of Mauritius has published the route. Its Guideline for Digital Banks came into force on 6 December 2021, drafted in consultation with the IMF's regional technical assistance centre for Southern Africa. It sets out a restricted phase of up to five years: a mobilisation period of no more than two, then a transitional period of no more than three. A restricted digital bank needs stated or assigned capital of at least MUR 200 million. During the transitional period its balance sheet is expected to reach MUR 2 billion. It must keep a principal place of business on the island, and that office may handle complaints and regulatory examinations, but it may not be used to conduct banking business with customers. Everything else happens through electronic means.
That is a demanding path. It is not an ambiguous one. The capital is a number, the timeline is a number, and the conditions are written down. Any competent adviser can tell you within a week whether you qualify.
What no guideline can inspect is whether your systems tell you the truth.
Failure in a digital bank is quiet
A branch that is closed is obviously closed. Someone tries the door. A digital bank fails differently, and that difference matters more than anything in the technology stack.
Four patterns we have seen in production, in live regulated financial businesses:
A prospect completes registration. An error appears on the screen that should take them to their dashboard. No confirmation email arrives. No record is created. The person exists only as a message in a support inbox, and only if they bothered to write one.
Two role addresses — the ones carrying account confirmations and withdrawal notices — were never verified with the mail provider. Every other address on the domain was. The two that mattered most were silently failing to deliver the two messages that mattered most.
A browser security interstitial sat in front of the domain for weeks. Some proportion of prospective customers saw a red warning page instead of a bank. That proportion is unknowable, because nobody who turns back at an interstitial appears in any analytics you own.
A public page presented instrument prices as live. They were not fed from a live source. Anyone checking a price against the market would have found the institution either careless or dishonest, and would have had no way to tell which.
None of these threw an alert. None appeared on a dashboard. Each one degraded a number that somebody, somewhere, was reporting as conversion, and each was discovered by a person stumbling into it rather than by a system designed to notice.
That is the actual risk profile of a digital bank. Not a dramatic outage. A slow, unmeasured leak between a customer's intention and a record in your database.
The migration problem is a truth problem
Most institutions entering digital banking are not starting from nothing. They are moving off something: a legacy core, a licensed vendor platform, a set of spreadsheets that grew teeth.
A widely repeated claim in the industry is that around 80 percent of core banking migrations fail, usually because of incomplete or incorrect data. It is worth being precise about that number. It comes from a vendor executive and is published without methodology, sample, or a definition of failure. Treat it as a sales argument, not a finding.
The underlying observation still holds, and it is more interesting than the statistic. Migrations fail on data, not on technology. The reason is that a migration is the first exercise that forces an institution to state, precisely, what its records mean. Which of these two customer rows is the real one. What this status code meant in 2019. Whether a balance is authoritative or derived. Systems tolerate that ambiguity for years. A migration does not.
This is why migration timelines slip in a characteristic way: fast until the first reconciliation, then not at all. The engineering was never the constraint.
What we would actually do
None of the following is novel. All of it is routinely skipped.
Instrument the funnel before you need it, not after. If you cannot say how many people started registration yesterday and how many finished, you cannot detect the failure described above. You can only wait for someone to complain. Attribution and conversion events are cheap to add at the start and expensive to backfill.
Test the paths nobody tests. Signup gets tested because it is the demo. Password recovery, email verification, withdrawal, account closure and the error branches do not, and those are where the quiet failures live. Every one of the four patterns above sits outside the happy path.
Treat every public claim as an assertion under test. If the site says funds are segregated, latency is 14 milliseconds, or onboarding takes 180 seconds, something should be checking. In a regulated business those sentences are not marketing copy. They are representations, and a regulator reads them that way.
Make failure loud. A registration that creates no record should page someone. A confirmation email that does not send should raise an alarm. The engineering cost of that is small. The cost of not having it is a number you will never be able to calculate, because the customers it lost never entered your system.
Decide what your records mean before you migrate them, not during. The data-quality work is the migration. Scheduling it as a phase inside the migration is how five-week cutovers become five-month ones.
The part that is actually hard
Mauritius has made a deliberate bid to be a place where this can be done properly. The digital banking guideline, the Mauritius Central Automated Switch introduced in 2020, and the wider financial services framework are all serious pieces of infrastructure. The jurisdiction is not the obstacle.
Neither, in the end, is the licence. Capital can be raised and conditions can be met, and there are advisers who do nothing else.
The hard part begins the day after authorisation, and it is unglamorous. It is whether the system behind the application tells you when it has failed. A regulator asks, once, whether an institution can be trusted with other people's money. The institution's own systems answer that question every day, silently, whether or not anyone is reading the answer.
Elementary architects enterprise platforms, AI agent systems, sovereign infrastructure and regulated fintech for institutions that require auditability, resilience and precision. The operational patterns described here are drawn from our own production work, generalised and stripped of client detail.
References
- Bank of Mauritius, Guideline for Digital Banks, in force 6 December 2021.
- Bank of Mauritius, Mauritius Central Automated Switch (MauCAS), introduced 2020.
- The 80 percent migration-failure claim is attributed to Karl im Brahm, CEO DACH at Objectway, and is published without supporting methodology.