You cannot take it down
Somebody is opening a bank account at every hour a branch is open, and law enforcement does not keep office hours. Change has to be deliverable without an outage, which rules out a whole class of convenient shortcuts.
Case study · United Arab Emirates
The national-ID authentication layer for the UAE's regulated economy.
Every regulated entity in the UAE — government, banking, telecom, law enforcement — needs a single trusted way to authenticate the national ID. Our team designed and built the cross-platform SDK and online Validation Gateway that does it.
2017In production since
40M+Identities managed
2M+Authentications per day · all implementations
1.3MAuthentications per day · UAE national alone
99.99%Availability observed across implementations
How it fits together
One integration layer, every relying party.
Rather than each regulated entity building its own path to the national ID register, they integrate once — against an SDK and gateway our team designed, built and still supports.
Relying parties
Regulated entities
Designed & built by the team
National ID SDK + online Validation Gateway
Authoritative record
National ID register
The problem
One credential, and every institution needing to trust it.
A national ID card is only as useful as the number of places that can verify it. Issuing 40 million credentials achieves nothing on its own — the value appears when a bank branch, a telecom shop, a ministry counter and a police terminal can each satisfy themselves, in seconds, that the person in front of them is who the card says they are.
Left to itself, that becomes a fragmentation problem. Every institution builds its own reader integration, its own certificate handling, its own path to the register. Each one is a separate implementation to secure, a separate thing to break when the card changes, and a separate place for the authority to lose visibility.
The alternative is one integration layer that every relying party uses, maintained centrally by people who understand both the card and the register. That is what our team designed and built.
What we built
A cross-platform SDK, and the gateway behind it.
Smartcard depth on the client side, a hardened validation service on the server side, and the operational discipline to keep both running for the better part of a decade.
The SDK — what a relying party integrates against
- Cross-platform. A bank on one stack and a ministry on another integrate against the same interface, so the authority maintains one contract rather than a dozen
- Native smartcard and PKI handling — card authentication, certificate lifecycle, secure messaging. The parts institutions most often get wrong when they build it themselves
- Engineered to Common Criteria standards by a team with EAL1–EAL4 evaluation experience
The online Validation Gateway
- The online path from a relying party to the authoritative national ID register
- Carries the authentication traffic of the UAE's regulated economy — government, banking, telecom and law enforcement
- Availability observed at 99.99% across implementations
Scale in context. 1.3 million authentications a day on the UAE national system alone, and more than 2 million a day across all implementations. Those are sustained figures, not peaks.
Operating it
There is no maintenance window nobody notices.
When a country's banks, telcos and ministries all authenticate through one path, the engineering standard is different from a normal integration project. Three constraints shape everything.
You cannot break an integrator
Every relying party integrated on its own timetable and upgrades on its own. An interface used by dozens of institutions has to stay backward compatible far longer than a normal product would, because you cannot make a national bank redeploy to suit your release.
You cannot guess at failure
A failed authentication is somebody standing at a counter unable to complete what they came for. Diagnosis has to be possible from the outside, quickly, without access to the relying party's systems.
Nine years on
Anyone can build a version one.
The system went into production in 2017 and the same team still operates it. That distinction matters more than it sounds. Most identity vendors can show a successful launch. Very few can show what happens afterwards — when card generations change, when a relying party integrates something unusual, when volumes double, when the people who wrote it have moved on.
We have not moved on. The engineers who designed the SDK and the gateway lead delivery at Aptiway today, which is the entire reason the firm exists in this shape. When we take on a national programme, the knowledge that normally leaves with a supplier stays with the client.
What this means if you are buying. Ask a prospective vendor not what they have launched, but what they are still running, and who is still on it. That question separates the field quickly.
Why it matters
This is the part that is hard to buy.
It is infrastructure, not a product
When every bank, telco and ministry in a country depends on one authentication path, it stops being a system anyone can treat as a deliverable and starts being something that has to be run.
It has run for years
In production since 2017. Most identity vendors can show a pilot. Far fewer can show a near-decade operational record on a national system.
The same people are still here
The engineers who designed the SDK and gateway lead delivery at Aptiway today. That is the whole reason the firm exists in this shape.
Planning a national identity programme?
We have built one that a regulated economy runs on, and we are still operating it.