Yes. E-money still has to reconcile against a safeguarding account held at a bank, and a single-entry design, where a balance is a mutable number on an account row, cannot demonstrate that the sum of customer balances equals what is actually safeguarded. Double-entry is not an accounting preference here; it is the only structure that makes the safeguarding obligation provable at any moment rather than reconstructable at month end.
The shortcut is tempting because early e-money products look simple: money in, money out, a number goes up or down. The problem appears at the first partial reversal, the first disputed transaction, or the first time a regulator asks how a balance was arrived at. With mutable balances there is no record of the movements that produced the number, only the number, and the history has to be inferred from application logs that were never designed to be evidence.
Double-entry solves this by making every movement two entries that must sum to zero. The safeguarding reconciliation then becomes a query, not a project: total customer liability on one side, safeguarded funds on the other, and any difference is a real difference rather than a reporting artefact.
The cost of adding it later is not the schema migration. It is that the history you need to reconstruct was never recorded in the right shape, so the opening balances of the new ledger are an assertion, not a derivation. Which is precisely the thing an auditor will ask you to prove.
The one genuine exception is a product that never holds customer funds at all, where money moves directly between two regulated parties and you are only orchestrating instructions. If you are holding, you are safeguarding, and if you are safeguarding, you need to be able to prove it.