Continuous Authentication Is Coming to South African Banks. The Failure Path Matters More Than the Feature.

This week Flownamix Group brought continuous facial authentication to South Africa through African licence holder ExSo, with distribution through Datanamix, SigniFlow and SMSFlow. The technology, built by YEO Messaging, is being pitched first to banks, insurers and fintechs. Instead of one face scan at login, continuous facial recognition checks that the person holding the phone is still the person who opened the app, using facial mapping, depth sensing and liveness detection for the length of the session. That strengthens in-app security. It is also a system that now gets far more chances to get you wrong.

More checks means more chances to misjudge someone real

A one-time login check gives a system exactly one moment to misread a legitimate user. Continuous verification runs all session long, so the same system now gets dozens of chances to misjudge the same person: a bad angle, low light, a new haircut, a phone propped against a laptop. None of that is a security failure. It is a false negative: a real customer told, mid-payment or mid-claim, that the system does not believe they are who they say they are.

Building identity verification into paid products taught me which part of this gets argued about at launch, and it is never the part the vendor's slide deck covers. The pitch is always about catching fraud. Almost nobody asks what the app should do the instant it misreads a real person mid-session, and that gap is the real product decision inside every one of these rollouts.

What we built when verification had to fail without locking someone out

On a South African prize and prediction platform we built, verification is not decorative. A national ID check functions as a prediction ticket, and a credit bureau opt-in unlocks a multiplier on it, so a verification error has direct financial consequences for a paying customer. We deliberately did not build it as a silent hard gate. When automated verification failed or came back uncertain, the system did not lock the account or dead-end the user. It routed them to a human support channel, so someone who was clearly who they claimed to be could get unblocked.

We have written before about what compliance-by-design identity verification looks like on a regulated South African platform, and the same principle applies here: the engineering decision was never "make verification stricter." It was "decide, before launch, what happens to a real customer the instant the machine gets it wrong," and build that path into the system rather than patch it in after the complaints start.

What this means if you are the one signing off on it

If you run a bank, insurer, fintech or any business about to add continuous facial checks to a customer-facing app, the vendor conversation will centre on accuracy, liveness detection and fraud prevention. Ask a different question: what happens to a legitimate customer the moment the system flags them mid-session. Is there a human path, a retry with a different method, a short grace window, or does the app just lock them out. That answer, not the accuracy claims on the data sheet, is what your customers will live through, and it is decided by whoever builds the app, not the vendor selling the biometric layer. This is exactly the kind of decision we help clients think through when we scope custom software builds for regulated financial products here in South Africa.

Continuous authentication is coming to South African financial services whether or not any one bank moves first, because it is already being sold as the new baseline for in-app security. The underlying technology will keep improving. That decision will not improve on its own, and it is the one that determines whether people trust the system or start looking for a way around it.