Writing · Human Layer

Securing borderless money: the cyber risk behind the stablecoin super bank

By Mahmoud Lotfy · Jul 2026 · 7 min read

When 70% of a 500 million person market banks through a wallet instead of a branch, the security question changes shape. On Tencast, Kem's founders described a stablecoin super bank that onboards a user in about a minute and hands them self-custodial, dollar-pegged money that is borderless on day one. That is a genuine solution to a real access problem. It is also a threat-surface story. When onboarding is instant and there is no bank in the middle to reverse a mistake, the primary attack vector is no longer the rails. It is the human being asked to approve.

I look at every new financial product through one lens: where does a person become the point of failure? For a traditional bank, there are days of friction, manual review, and reversibility that quietly absorb a lot of risk. Strip that friction away in the name of inclusion, which is exactly the right goal, and the risk does not disappear. It moves. It moves to identity, to onboarding, and to the moment a user taps approve.

Access as the new perimeter

The problem Kem is solving is real and specific. Roughly 70% of the region's 500 million people are underbanked or unbanked, and many foreigners simply cannot open a local account at all. One founder described living in Kuwait for years without ever being able to open a bank account because the system did not serve foreigners. A borderless, dollar-pegged wallet that anyone can set up in seconds is a serious answer to that. The founders note that stablecoins are already processing more volume than Visa and Mastercard combined, so this is not a fringe experiment. It is where money is going.

But speed of access is also speed of exposure. In the old model, the perimeter was the account: hard to open, therefore hard to abuse at scale. In the new model, the account is trivial to open, so the perimeter collapses onto identity and onboarding. If a bad actor can pass onboarding in a minute, or socially engineer someone who already has, the borderless design that helps a legitimate user helps them too. The same properties that make the product inclusive, no gatekeeper, no friction, instant reach, are the properties an attacker studies first.

"As soon as you switch into crypto, all of that's gone. You're borderless on day one."

The human layer of self-custody

Self-custody is the sharpest edge. When a user holds their own funds, there is no bank to call, no chargeback, no reversal. That is a feature for sovereignty and a liability for human error. Phishing, approval fraud, and social engineering do not need to break any cryptography. They need to convince one person to authorise one transaction, and the money is gone with a finality that traditional banking does not have.

This is the same pattern I see everywhere in security: the technical controls hold, and the attacker walks through the human instead. In a self-custodial wallet, that human is not a trained employee behind a control framework. It is a first-time banking customer, sometimes someone who, as the founders put it, just received their first card ever. The threat model has to start from there, not from an idealised user who reads every warning.

Designing controls that do not kill inclusion

The wrong response is to bolt on so much friction that you reintroduce the exclusion you set out to fix. The right response is to put the intelligence where the risk actually is: the moment of approval. This is the scope-to-authority idea I build Excera around. Brief each user, in their own language, on exactly the decisions that can hurt them, moving money, granting access, approving an action, and match the verification to the stakes of that specific decision rather than the whole product.

Concretely, that means the heaviest checks land on the highest-consequence, irreversible actions, and the everyday flow stays fast. It means warnings that are specific to the attack, not generic legalese a user swipes past. And it means treating security awareness as a native part of onboarding for people who may never have had a bank account, not an afterthought written for a corporate employee. Inclusion and safety are not opposites. They fail together when you design for a user who does not exist.

What regional fintechs should harden first

If I were advising a fintech building on these rails, I would harden three things before anything else. First, onboarding identity, because in a borderless model it is the whole perimeter. Second, the approval moment for irreversible actions, because that is where self-custody turns a mistake into a permanent loss. Third, human-layer awareness delivered in the user's language at the point of risk, because the attacker is aiming at the person, not the protocol. The founders are right that the opportunity here is massive. The teams that capture it safely will be the ones that treat the human approving the transaction as the real product surface, and secure it accordingly.