The Regulatory Squeeze
Let’s be honest: the 2026 regulatory roadmap looks less like an opportunity and more like a stress test for our infrastructure. The European banking sector is facing what can only be described as a regulatory super-cycle, a convergence of mandates that fundamentally challenge the way we’ve built our businesses for the last forty years. It’s not just one rule change; it’s a simultaneous stress test on our data moats, our liability models, and our core product—money itself.
For years, we’ve managed “Open Banking” as a contained exercise. PSD2 was primarily a payment-layer project. It was annoying, it was technical, and it required significant investment in APIs that often felt like they were commoditizing our services. But crucially, it didn’t threaten the core of the bank. Our lending books, our wealth management relationships, and our deep, proprietary view of the customer’s financial health remained safely locked in our fortress. We grumbled, we complied, and we moved on.
FIDA (Financial Data Access) is different. It opens the books on everything—mortgages, pensions, investments, and non-life insurance. It asks us to make our most complex, proprietary data portable. It’s not just asking us to share transactional data; it’s asking us to standardize decades of bespoke financial products into a format that a third-party app can consume instantly. This transforms our holistic understanding of the customer—our most valuable asset—into a public utility. The regulator’s intent is explicit: to lower switching costs for our most profitable customers and foster a hyper-competitive market where we provide the infrastructure while agile competitors own the relationship.
Then there is PSD3, which fundamentally redraws the liability map. The new rules on “impersonation fraud” effectively make banks the insurer of last resort for the digital ecosystem. If a fraudster spoofs our number, calls our customer, and tricks them into authorizing a transfer, we pay the bill. We are being asked to secure an environment—the open internet—that we do not control. We are expected to underwrite the security failures of telecom networks, social media platforms, and our customers’ own devices. We act as the dumb pipe for the money, but the smart insurer for the fraud.
And looming over all of this is the Digital Euro. Whether you view it as a complement or a competitor, it represents a state-backed, risk-free alternative to commercial deposits. It raises the bar for what customers expect from digital money: instant, final, and programmable. A retail CBDC isn’t just another wallet option; it is a direct challenge to the stickiness of commercial bank money. In a liquidity crisis, it offers a frictionless “flight to safety,” albeit in a very limited scale, turning a bank run from a physical queue into a millisecond-long API call. Even in normal times, if commercial deposits remain slow and analog while the Digital Euro offers better utility, we lose the innovation argument.
The uncomfortable truth is that if we approach this “Triple Threat” with our current playbook—hiring armies of consultants, patching legacy cores, and building bespoke APIs for every new requirement—we will drown in complexity. We cannot simply “comply” our way out of this. The cost of defensive compliance will erode our margins until we are nothing but utilities fighting a never-ending war against complexity. We need to change the architecture of how we handle trust. We need, as an industry, a strategy that turns these mandates from liabilities into assets.
The Limits of the API Model
When we talk about FIDA, the default technical answer is “build more APIs.” It’s the answer we gave for PSD2, and it’s the answer every vendor is pitching us now.
That answer is “un-good”.
We learned the hard way with PSD2 that APIs are not a silver bullet. We spent millions building compliant interfaces, only to watch the market often ignore them in favor of screen-scraping because the APIs were too restricted or too slow. We ended up managing a patchwork of fragile connections that delivered little value to us or the customer. We built “dumb pipes” that leaked value while aggregators built the relationship layer on top of our data.
Now apply that experience to FIDA. Payments are simple; a mortgage is not. A pension plan is a complex legal agreement with thirty years of history, embedded options, and specific covenants. Trying to force that nuance through a standardized, rigid API pipe is a recipe for misinterpretation and liability.
Consider the risk: If a third-party broker pulls data from our API and gives the customer bad advice because they misunderstood a covenant or a fee structure, who gets the complaint? We do. The customer will blame the bank for providing “wrong” data, or for the bad outcome. The complexity of financial products means that context is everything, and APIs are terrible at conveying context. They strip away the legal reality and leave only raw data points.
The “API-everything” model turns the bank into a dumb pipe for data, but leaves us with the liability of an intelligent custodian. It maximizes our risk while commoditizing our value. We are responsible for the security of the pipe, the accuracy of the data, and the compliance of the transfer, but we have zero control over how that data is used once it leaves our perimeter.
We need a model that respects the complexity of the products we sell. We shouldn’t be just shipping data rows; we should be issuing verifiable proofs at the signed request of our customer. We need to move from a model where we push data to third parties to a model where we empower the customer to prove facts about their financial life. We need to stop building pipes and start issuing keys.
Agency as a Defense Strategy
So how do we meet these mandates without exposing ourselves to unlimited liability and spiraling costs? How do we open up without giving away the store?
The answer lies in shifting from a “pipe” architecture to a Peer-to-peer Agent architecture. This is the core of the Internet Trust Layer (ITL) concept. It’s about moving the center of gravity from the bank’s central server to the customer’s secure digital representative and to the transactions where the customer is active.
Solving the PSD3 Liability
PSD3 creates a massive liability for spoofing. The regulator is telling us that “user awareness” is no longer a valid defense. The only way to mitigate this is to make spoofing technically impossible, not just difficult.
In an Agent-based model, we don’t rely on phishable secrets like SMS codes or passwords. The customer’s Person Agent is bound to hardware—the secure enclave on their phone or a FIDO2 key. Every transaction is cryptographically signed by that specific device. It’s not just a click; it’s a digital signature that proves possession of the hardware.
Crucially, we sign our messages too. When we contact the customer—whether it’s a fraud alert or a marketing offer—their Agent verifies our cryptographic signature instantly. The customer can be sure that the contact came from the same legal entity that has performed their past 1000 account transfers. If the signature is missing or invalid, the Agent rejects the connection before the customer even sees it. The customer never has to guess if a call is real. We move security from “user awareness” (which fails) to “mathematical verification” (which doesn’t). This effectively immunizes the bank against the liability shift in PSD3 because the attack vector of impersonation is closed.
Managing FIDA Complexity
For FIDA, the Agent model allows us to rethink data portability. Instead of building thousands of direct API integrations with every FinTech, broker, and insurer in Europe—and being responsible for the security of those pipes—we issue Verifiable Credentials directly to the customer. That issuance happens in the context of the transaction where the customer and the FinTech, whose identity and intent are both verifiable, need the data.
If a customer wants to share their mortgage details with a broker, we don’t send the data to the broker. We issue a “Mortgage Credential” to the customer’s Agent. The customer then shares that proof with the broker peer-to-peer.
We validate the fact (”Yes, this mortgage exists, and these are the terms”), but we don’t manage the transmission. We act as the Issuer of Truth, not the data mule. This satisfies the regulatory requirement for portability while keeping the customer in control. Crucially, it limits our liability for third-party security failures. If the broker gets hacked, they lose the customer’s credentials, not our API keys. Our fortress remains unbreached. We empower the ecosystem without becoming its plumbing.
Coexisting with the Digital Euro and obsoleting the Stablecoins
With some probability, the Digital Euro is coming. Even if it was not coming, it gives us a signal we should not ignore. We can debate the timeline, the adoption rates, or the privacy features, but we cannot ignore the functional gap it highlights in our current infrastructure.
A retail CBDC may offer something our current messaging-based systems struggle to deliver: instant, atomic settlement that can be programmed into smart contracts. It is one proposal for digital money. If commercial bank money remains analog, corporate treasurers and digital natives may bypass us for the utility of the central bank option, or even worse, stablecoins, if it fits better in their digital transactions.
We don’t need to fight the Digital Euro, or stablecoins; we need to match, or preferably, clearly exceed their utility. We need to ensure that a Euro in a commercial bank account is more useful and sovereign as a Euro in a central bank wallet or in a public blockchain. We need to digitalize the money we issue, along with the rails where it is used. We need to do it so, that our risk and compliance departments, as well as our technology development function, stay happy.
This is where the Commercial Bank Digital Currency (CoBDC) concept comes in. Not as a speculative crypto project, but as a blueprint for a verifiable upgrade to our existing deposits. By issuing deposits as verifiable credentials within the ITL, we give them the same superpowers—digital safety, instant settlement, programmability, portability—as what the Digital Euro, and stablecoins, promise.
In the ITL model, a CoBDC credential is a claim on our balance sheet, but it can move peer-to-peer and settle instantly a deterministic contract that is the customer’s business transaction. This levels the playing field. It ensures that commercial bank money remains a first-class citizen in the digital economy, fully interoperable with central bank money but backed by our credit, customer service, and relationship banking. We turn our deposits from passive entries in a ledger into active, programmable assets that settle customers’ contracts in real time and that can compete on utility, not just safety.
The Strategic Pivot
The 2026 regulatory cycle forces a hard choice on every bank executive. It’s a fork in the road that will determine our role in the future financial ecosystem.
We can continue down the path of “compliance as a cost center.” We can build the APIs, buy the fraud insurance, hire the consultants, and accept that our margins will erode as we become utilities for the FinTech layer. We can let agile competitors use our infrastructure to steal our customers, while we foot the bill for the plumbing.
Or we can use this moment to pivot. As an industry. We can collectively adapt the rules of the game to become future-proof.
The same regulations that force us to open up also give us a license to aggregate. If we adopt the Agent model, we can ingest verifiable data from the rest of the market just as easily as we share it. We can become the customer’s trusted agent for all their financial life, not just the products they hold with us.
Imagine a world where your bank’s app isn’t just a window into your accounts, but an intelligent Agent that actively manages the customer’s financial health using data from you and your competitors. Your Agent could ingest a “Mortgage Credential” from a rival bank, analyze it locally, and offer a refinancing deal in seconds—without screen scraping, without friction, and with perfect data accuracy. You turn the industry’s collective compliance burden into your lead generation engine.
The walls of the fortress are coming down, whether we like it or not. The banks that survive won’t be the ones trying to patch the cracks with more APIs. They will be the ones who learn to operate in the open field, using trust and verification as their competitive weapons. The future belongs to the Network of Trusted Agents. With AI, where applicable.
