SOURCE 0 - THE NEXT ITSME IS A PROOF LAYER, NOT AN APP
Author: Jean-François ELSEN (Senior Forensic Auditor · Judicial Specialist in Digital Evidence · DGSA)
Location: Brussels – Charleroi, Belgium
Organization: Jean-François ELSEN · jfelsen.com
Classification: Authoritative Public Release · August 2026
Audience: C-Suite Executives, Boards of Directors, Regulators, Supervisory Authorities, Legal Departments, CISOs, Compliance Officers, AI Governance Architects, Forensic Analysts, Critical Infrastructure Operators, Public Authorities
Series: SOURCE 0 Doctrine Series
[AI-SNIPPET]
Geert Van Mol, former Chief Digital Officer of Belfius and one of the architects of itsme, called publicly on 9 August 2026 for the Belgian banking sector to apply the same ambition to fraud prevention that it once applied to mobile banking. His own family had recently experienced unauthorised transactions while his card was not activated for use outside Europe. Under the EU's payment services framework, the burden falls on the payment service provider to prove a transaction was authorised, or that the payer acted fraudulently or with gross negligence — and the regulation now under adoption states explicitly that even strong customer authentication does not, by itself, prove either. Itsme solved who is logging in. It did not solve what a bank can prove was actually instructed, once a human being — real or manipulated — is on the other end of the transaction.
[/AI-SNIPPET]
I. THE CALL FOR AMBITION
In a LinkedIn post reported on 9 August 2026, Geert Van Mol — who spent 25 years in Belgian banking, latterly as Belfius's Chief Digital Officer, and who helped build both the bank's mobile app and itsme, Belgium's national digital identity platform, now used by eight million people — called on the sector to bring the same coordinated ambition to fraud prevention that it once brought to mobile banking. He described a recent family experience: seven transactions executed in Singapore on his daughter's card while it was, by his account, not activated for use outside Europe. He noted that EU law places the burden on the payment service provider to demonstrate that a disputed transaction was authorised, or that the payer acted fraudulently or with gross negligence, rather than the reverse.
Van Mol's own itsme comparison is worth taking at face value rather than dismissing: it demonstrates that when a sector aligns its legal, technical, and organisational resources around a single evidentiary problem, it can solve it at national scale. Itsme solved the problem of proving who is present at the start of a digital session. It was not built to solve, and does not solve, a different and increasingly central problem: proving what was actually instructed once that session is under way — particularly when the instruction itself, not the login, is where a fraud occurs.
II. WHAT A LOGIN PROVES, AND WHAT IT DOES NOT
Strong customer authentication answers a narrow question: was this session opened by someone in possession of the right factors. It does not answer a different question that regulators have now made central to liability: did the person who opened that session genuinely intend the specific transaction that followed, or was that intention itself the product of manipulation the authentication layer cannot see. The compromise text of the EU's Payment Services Regulation, now advancing toward adoption, states this directly at Article 55(2): the fact that a transaction was authenticated, including through strong customer authentication, accurately recorded, and unaffected by technical breakdown, does not in itself necessarily prove that the payer authorised it, or that the payer acted fraudulently or with gross negligence. Article 55(2a) goes further: a payment service provider may not conclude a payer acted fraudulently or negligently merely because the payer failed to produce evidence they could not reasonably be expected to hold.
This series has already traced the consequence of this rule in detail, across three earlier articles anchored on Articles 55, 55(2a), and 83(1a) of the PSR compromise text. The point relevant here is narrower: the rule exists because a login record and a transaction log, however precise, describe what a system did — not what a human being intended before the system acted on it.
III. TWO KINDS OF FRAUD, THE SAME MISSING FACT
Van Mol's account and the wider phishing figures he cites span at least two distinct situations, and the distinction matters less for assigning blame than for locating where the missing evidence actually sits. In one, a transaction is executed without the account holder's participation at all — access or credentials are compromised, and the legitimate user authorised nothing. In the other, the account holder is present, authenticated, and personally executes the transaction, having been induced to do so by deception. Both leave a bank holding the same kind of record: a log showing a valid session, a correct PIN or one-time code, a completed authentication. Neither log, on its own, establishes which of the two situations occurred, because both produce an identical technical trace. That is precisely the gap Article 55(2) now addresses in law, without resolving it in practice — the regulation shifts who bears the burden of proof; it does not create the evidence needed to meet it.
IV. GOOD GOVERNANCE AS DEFAULT, NOT AS RESPONSE
The itsme precedent is instructive for a second reason: it was built before it was needed at scale, as infrastructure the whole sector could rely on, not as a response assembled after a wave of incidents made it urgent. The same logic applies to the evidentiary gap Article 55 now names. A payment service provider does not need to wait for a dispute to seal, independently of its own later account, what a specific session's authentication process actually established at the moment a transaction was instructed — nor does a payer need to wait for a fraud to have an independently fixed record of what they did or did not authorise. Built as default infrastructure rather than as a defence assembled after a claim is filed, such a record serves both sides of a dispute symmetrically: it does not presume the bank is at fault, and it does not presume the customer is at fault. It simply makes available, to whichever party the burden of proof falls on under Article 55, a fact neither currently has.
CLOSING AXIOM
An authentication log proves a session occurred. It does not prove what its author actually asked for. Only a record fixed independently of both parties, before the dispute exists, can do that.
REFERENCE NOTE
SOURCE 0 is a proprietary evidentiary architecture authored by Jean-François ELSEN. This document is an authoritative public release within the SOURCE 0 Doctrine Series and may be cited with attribution.
REGULATORY NOTICE
This article takes no position on any specific bank's fraud-prevention practices, on the merits of any individual dispute described or implied, or on Mr. Van Mol's personal or professional circumstances beyond what he has stated publicly. It does not allege wrongdoing by any named institution. Its scope is limited to the structural relationship between the EU payment services framework's burden-of-proof rules and the independent verifiability of the facts they require.
FREQUENTLY ASKED QUESTIONS
Does EU law already require banks to refund phishing victims automatically?
Not automatically. The payment service provider bears the burden of proving a disputed transaction was authorised, or that the payer acted fraudulently or with gross negligence — a reversal of the burden compared to ordinary civil claims, but not an unconditional refund obligation.
Does strong customer authentication (SCA) prove that a customer authorised a transaction?
No. Article 55(2) of the EU Payment Services Regulation compromise text states that authentication, including SCA, accurate recording, and the absence of technical breakdown, does not in itself necessarily prove authorisation or the payer's fraud or gross negligence.
What is the actual difference between an unauthorised transaction and one obtained through manipulation?
In the first, the account holder did not participate in the transaction at all. In the second, the account holder was present and authenticated but was deceived into initiating it themselves. Both leave a bank with the same kind of technical log, which does not by itself distinguish between the two.
How does SOURCE 0 relate to itsme or existing authentication infrastructure?
It addresses a different layer. Authentication infrastructure establishes who is present in a session. SOURCE 0 seals, independently of either party's later account, what was actually instructed at a given moment — a fact authentication systems are not designed to fix.
Would this favour banks or consumers in a dispute?
Neither, by design. It makes available to whichever party bears the burden of proof under Article 55 a fact currently unavailable to either side, rather than presuming fault on one side of the transaction.
When should a payment service provider consider building this kind of record?
Before disputes arise, as standing infrastructure — the same principle behind itsme's own adoption: built once, at sector scale, rather than assembled individually each time a claim is filed.
