White paper — FinTech & digital banking: transforming financial services

White paper · November 2025

FinTech & digital banking: transforming financial services

Making money and data flow — without ever losing trust

“The players who suffer are not the ones with an old app — they are the ones who believed the transformation was an app.”

4 texts

1 journey

90 days

PSD2, DORA, MiCA, AML-CFT — the regulatory base put in order, and what converges

A payment's, from initiation to settlement — and the five places where it breaks

The action plan, from the journey map to the first crisis exercise

This white paper draws on the digital-steering experience of the Clarendis network in financial services, in France and in Switzerland; it reads on its own, and re-reads at every new transformation project.

Contents

Foreword 03 Executive summary — the document in ten statements 04 Your reading path 06 1 The digital-banking misunderstanding The app is not the transformation · Banking is a flow of trust · What the status quo costs · The three houses: private bank, fintech, embedded finance 07 2 The regulatory base: a funded architecture blueprint PSD2 and open banking · DORA, operational resilience · MiCA and crypto-assets · AML-CFT · Licences: which one for what · What converges — and the Swiss counterparts 12 3 The architecture: the core, the APIs, the data Core banking, asset and liability · The real journey of a payment · APIs and open banking · Client data and KYC · Cloud and critical outsourcing · The vendor requirements grid 18 4 The blind spots Fraud at instant-payment speed · The legacy core · Critical providers and BaaS · Operations shadow IT · Credit journeys · Crypto-assets · The crisis never rehearsed 25 5 2026-2030: the trajectory Instant payments generalised · PSD3 and FIDA, open finance · From compliance to value · The no-regret decisions of 2026 · In the watch annex: AI, market consolidation 32 6 The 90-day action plan Where are you starting from? · D1-D30: see clearly · D31-D60: harden · D61-D90: prove it — pilot journey and crisis exercise · The five-number dashboard 36 Moving to execution 41 Appendices — Glossary, sources, about Clarendis, self-assessment, watch 42-47

Foreword

Financial services live a paradox. Never has the experience progressed so much — an account opens in eight minutes, a payment crosses Europe in ten seconds, financing simulates itself inside an e-commerce journey — and never have the two symmetrical complaints been so sharp: “our digital projects sink into the core system” on the private-bank side; “compliance costs us more than technology” on the fintech side. Experience and compliance are two faces of a single subject: mastery of the journey of money and client data. And almost everywhere, they are entrusted to teams that do not talk to each other.

This white paper was born of a market-wide observation: digital-banking projects that fail rarely stumble on technology — they stumble on an untouchable core, duplicated client data and unwritten responsibilities. The standards exist, the texts exist, the reference architectures exist. What is missing is a method that puts them in order, and that is what this document offers: the misunderstanding first (chapter 1), the regulatory base (chapter 2), the architecture (chapter 3), the blind spots (chapter 4), the European trajectory (chapter 5), and an executable plan (chapter 6). The framework described is that of the European Union and France; Swiss readers will find the correspondences with their own framework in chapter 2 — the architecture principles, for their part, know no border.

A point of intellectual honesty: we sell no core banking system, no payment platform, no compliance solution, and we receive no referral commission. Every regulatory statement rests on a public text, all listed in the appendix; what comes from field experience is flagged as such.

How to read this document. The chapters stand alone. If your projects are sinking, start with chapter 3. If the last internal-audit report worried you, chapter 2 puts the mille-feuille in order. If you are preparing for 2027 and open finance, chapter 5 awaits you. Each chapter closes with the same panel, what this changes for you , written for three readers: the executive, the CIO, the head of risk and compliance. Deliberately the same subject seen from three seats — because these projects fail precisely where leadership, technology and compliance do not share the same map.

Enjoy the read — and may your flows be safe.

Cédric Guittard

Anna Hoang

cedric.guittard@clarendis.com

anna.hoang@clarendis.com

for the Clarendis team

Executive summary

The document in ten statements. Each is developed and sourced in the chapter indicated.

1

2

The transformation is not an app. It is mastery of the journey of money and client data: who initiates, where it passes, who controls, who settles. The app is only the surface of that journey. (Chapter 1)

The framework is no longer a prospect — it is a given. PSD2 in force for years, DORA applicable since January 2025, MiCA deployed, AML-CFT reinforced: the question is no longer “must we?” but “where do we really stand?”. (Chapter 2)

3

4

The mille-feuille converges on four simple demands. The inventory (flows, providers, access), mastery of identities and client data, tested resilience, and proof. One well-run programme serves every compliance at once. (Chapter 2)

The first project is not the app — it is client data. A single client referential, a KYC that is not redone for every product, duplicates resolved: the most profitable workstream of chapter 3, and the most underestimated. (Chapter 3)

5

6

You do not escape the core — you isolate it. Replacing the core system is banking's riskiest project; strangling it behind an API layer and moving innovation to the periphery is the strategy that works. Deciding nothing, however, is the worst option. (Chapter 3)

Instant payments change the nature of fraud. Ten seconds to credit is ten seconds to defraud: control moves from the batch to the transaction, from overnight to real time. A fraud programme designed for next-day transfers is already obsolete. (Chapter 4)

7

8

Your providers are your risk surface. BaaS, cloud, payment processors, compliance tools in SaaS: DORA makes the outsourcing chain a governance subject — register, contracts, tests, exit. Reversibility is negotiated at signature. (Chapters 3-4)

Your blind spots are peripheral — therefore decisive. The operations spreadsheet, the credit journey that bypasses scoring, the core nobody can modify any more, the crisis never rehearsed: every blind spot in chapter 4 is a regulatory incident or a client blockage in the making. (Chapter 4)

9

10

Europe sets the horizon: open finance. Instant payments generalised in 2025-2026, PSD3 and FIDA in preparation, a digital euro under study: the 2026 choices — APIs, data, consent — decide the cost of 2028. (Chapter 5)

The constraint hides an asset. The same plumbing that satisfies the regulator opens three value streams: seamless journeys, data that serves advice and steering, and proven resilience that becomes an argument of trust. (Chapter 5)

Where to start, depending on your situation:

Nothing is mapped. Chapter 1 (what the journey demands), then straight to the 90-day plan of chapter 6, “cold start” sequence. Your absolute priority: the map of journeys and flows, and the state of your client data.

Projects are sinking into the core. Chapter 3: the strangler strategy and the API layer will show you where the path runs — rarely through the big replacement. Then chapter 4, §4.2: the legacy core is often the knot.

The audit or the supervisor has rung. Chapter 2 in full, then the crisis exercise of chapter 6 (D61-D90): a programme never put to the test is not a programme — it is a binder.

Your reading path

Three marked itineraries. The “what this changes for you” panels at the end of each chapter are written for your seat.

CEO Executive 25 minutes

CIO CIO / CTO 1 h 30

RISK Risk & compliance 1 hour

01 Executive summary

Full document recommended. Your critical path:

You live this subject daily. Your path:

02 chapter 1 (§1.3: what the status quo costs, in business language)

01 chapter 3 in full (the core, a payment's journey, the data, the vendor grid)

01 chapter 2 in full (the mille-feuille put in order, what converges)

03 chapter 5 (the 2026-2030 trajectory — observations, not predictions)

02 chapter 4 (your blind-spot map — legacy core included)

02 chapter 4 (the seven blind spots — your audit plan for the year)

04 chapter 6, §6.4 (the five numbers for your monthly agenda).

03 chapter 2, DORA (resilience becomes your specification)

03 chapter 3, §3.4 (client data: where KYC and quality meet)

You will know what to fund, what to demand, and how to verify progress.

04 chapter 5, §5.4 (the 2026 technical choices that commit 2030)

04 the six “Risk & compliance” panels, at each chapter's end.

05 chapter 6 in full — the plan is yours.

What you came looking for

Need

Where

In what form

A map of the regulatory framework that fits on one page

Chapter 2

PSD2, DORA, MiCA, AML-CFT, licences: who requires what, from whom, and what converges — with the Swiss counterparts

An architecture strategy that unblocks projects

Chapter 3

The isolated core, a payment's journey, client data, the vendor requirements grid

The blind spots of official programmes

Chapter 4

7 situations, each with its revealing question and its first move

A plan executable tomorrow

Chapter 6

90 days in three phases, one pilot journey, one crisis exercise, five numbers

Chapter 1

The digital-banking misunderstanding

1

Before talking APIs and core banking, the subject must be freed of its founding misunderstanding — believing digital banking is a matter of apps — and grounded in what it is: mastery of a journey.

1.1 The app is not the transformation

Ten years of “digital transformation” have produced a reflex: for every problem, an app. A mobile app rebuilt every three years, a corporate portal, an aggregator, a financing simulator — each bought for a real need, each adding its own client base, its journeys, its exports. The sector's most constant finding: the average institution does not suffer from a lack of applications — it suffers from an excess of applications that share neither identities, nor data, nor responsibilities.

Digital banking is not a collection of screens: it is a circulation system. An operation is born somewhere (a client, a merchant, a partner API), travels (initiation, controls, clearing, settlement), and commits someone (the client, the institution, the regulator). Every link of that journey asks exactly two questions: does the operation arrive fast and right? — that is the experience; is it controlled and traced? — that is compliance. Two questions, one journey: that is why this document treats both together.

This reversal has an immediate practical consequence: the first deliverable of a digital-banking project is not a mock-up — it is a map of journeys and flows. Who initiates which operation, in which channel, through which systems does it pass, who controls it, under which client identity? That map — one page per domain is enough — is the most profitable document of chapter 6, and the one most often missing.

A market-wide observation. When an institution takes its first census of the applications touching the client journey, the count almost always exceeds what the IT department knew by a third — the rest arrived through marketing, partnerships and subsidiaries. No malice anywhere: simply, nobody had the map. It is the most common starting point, and it is not shameful — it is just urgent.

1

Chapter 1 — The digital-banking misunderstanding FinTech & digital banking

1.2 What the framework already requires

Financial services are no longer a field of recommendations: they are an enforceable framework, built in layers since 2015, most of which is already in force. Five building blocks structure everything else:

Block

What it imposes

Where it plays out for you

PSD2 — payments and open banking

Strong customer authentication, account access for licensed third parties via API, fraud liability rules

Your authentication journeys and account APIs — their real quality, not their existence

DORA — Digital Operational Resilience Act , Regulation (EU) 2022/2554

In one sentence: your IT must withstand outages and attacks, and you must be able to prove it — risk management, provider register, tests, notification of major incidents. Applicable since 17 January 2025

Your outsourcing chain and your exercises — detailed in chapter 2

MiCA — crypto-assets

Licensing of crypto-asset service providers, stablecoin requirements, holder information

Any crypto offer, direct or in partnership — even “under consideration”

AML-CFT

Customer due diligence (KYC), transaction monitoring, suspicious-activity reports, asset freezes — and a European package hardening the whole

Your client data: reliable KYC is first of all reliable data

GDPR

Legal basis per processing, minimisation, individual rights — financial data is massively personal

Every new journey, every data share with a partner

Two readings of this table. The defensive one: “more obligations”. The accurate one: the regulator has built, standardised and made mandatory the foundations every local project used to reinvent — authentication, account access, resilience, customer knowledge. The remaining work is yours, but it is bounded: plug your systems cleanly into these foundations, and keep up the quality of what flows through them.

Hence the question that orders this whole document, to ask before any purchase: “for each operation, can we say who initiates it, where it passes, who controls it — and under which client identity?” Everything that follows is a method for answering yes.

1

Chapter 1 — The digital-banking misunderstanding FinTech & digital banking

1.3 What the status quo costs

The status quo — systems that do not talk, an ageing core, compliance playing catch-up — has a cost, but it is dispersed, hence invisible to budgets. Making it visible is the first act of governance:

The cost of re-typing. Every data item that does not circulate is re-entered — by an adviser, a middle office, the client themselves redoing their KYC for every product. Re-typing costs commercial time, and it costs abandonment: every field asked twice in an onboarding journey makes conversion drop. That is the commercial cost of non-circulation — and it can be measured; your acquisition funnels are enough to objectify it.

The cost of the standstill. A payment outage is not an IT incident: it is transactions that no longer settle, salary transfers on hold, clients changing institutions, and a supervisor asking for the incident report. The sector's public incidents converge: the order of magnitude runs in millions of euros and in points of trust — not counting what no figure captures: silent attrition.

The cost of the missed opportunity. A distribution partnership impossible for want of APIs, a savings product launched six months late for want of a configurable core, payment data unusable for advice: the status quo does not just cost — it prevents earning.

3 costs

1 map

2 questions

Re-typing · standstill · opportunity — to objectify in your own numbers

Of journeys and flows — the first deliverable, before any purchase

Fast and right? Controlled and traced? — on every operation

1.4 Who this document is for

We write for three houses that share the same obligations with very different means: the private bank (wealth management and banking for entrepreneurs and families, in France as in Switzerland — rich in a core and a compliance function, heavy with both, and whose clientele forgives no approximation), the fintech (payment or e-money institution, neo-bank — agile, but whose compliance conditions its licence and its funding rounds), and the company that embeds finance (retailer, platform, software vendor integrating payment or financing into its offer — embedded finance, where one becomes a regulated actor without always having anticipated it). The principles are common; where a recommendation diverges by house, we flag it.

One conviction to close this chapter: in finance more than anywhere, technology serves one simple promise — that the client's money goes exactly where they decided, fast, and that nobody else touches it. Every page that follows is judged against it.

1

Chapter 1 — The digital-banking misunderstanding FinTech & digital banking

1.5 The three houses, in practice

The principles of this document are common; their implementation differs deeply by house. For each: the most profitable entry point, and the most frequent mistake:

House

The profitable entry point

The frequent mistake

The chapter to read twice

Private bank — wealth management, group subsidiary

The API layer above the core, and the single client referential — innovation at the periphery, the core stabilised

Launching the “big replacement” of the core without having isolated what depends on it — years of tunnel, value only at the end

Chapter 3 — the core, asset and liability

Fintech — payment, e-money, neo-bank

Compliance as a product: fluid KYC, tooled AML, demonstrated DORA — the argument that wins banking partnerships

Treating compliance as debt to pay “after growth”, when the licence and the partners set it as a prerequisite

Chapter 2 — the base, offensive version

Embedded finance — retailers, platforms, software vendors

The responsibility matrix with the regulated partner (BaaS): who carries KYC, fraud, complaints — in writing

Believing the partner's licence covers everything: reputational responsibility is never outsourced

Chapters 3-4 — providers and BaaS

Three houses, one common point: none can treat the subject in a silo any more. The private bank depends on fintechs for its journeys; the fintech depends on banks for its safeguarding accounts and partnerships; the embedded company depends on both to exist. The quality of the system is decided at the seams — exactly where this document places its chapters 3 and 4.

For the smallest structures. If you have neither CIO nor CISO, the document still reads in an hour via the “Executive” path — and the chapter 6 plan reduces, for you, to five gestures: the journey map on one page, a de-duplicated client referential, MFA everywhere, the responsibility matrix signed with every critical provider, and one incident exercise played once. That is already 80 % of the way.

1

Chapter 1 — The digital-banking misunderstanding FinTech & digital banking

The dated-decision template, to copy as is

As in every volume of this collection, everything begins with one signed page. In finance it has an extra virtue: it materialises leadership's responsibility on a subject the resilience regulation (DORA, chapter 2) now explicitly assigns to it.

Decision to bring flows and journeys under control

“[Date]. The management of [institution / company] decides to bring the journeys of money and client data under control: experience and compliance, run as a single programme. [First name Last name] is appointed as its lead. Milestones: map of journeys and flows within 30 days; state of client data and of the provider register within 60 days; first journey hardened end to end and first crisis exercise within 90 days. A dated log of incidents and decisions is opened as of today. Signature.”

This text is sent to no one: it is an internal note. It dates your trajectory — useful to the supervisor, indispensable to your teams. Five lines dated today are worth more than ten pages dated the next incident.

What this changes for you

CEO

CIO

RISK

Executive. Sign the dated decision above this week — one page, one lead, three milestones. And ask the two-number question: how many applications touch the client journey, and how many does IT know about. The gap is your real roadmap.

CIO. The first deliverable is the map of journeys and flows, not a target-architecture diagram. One page per domain: who initiates, where it passes, who controls, under which identity. Chapter 3 gives you the grid to fill it in.

Risk & compliance. The same flow map is your risk mapping, made alive. Every unmapped flow is at once an AML hole and a DORA blind spot: you now share an argument with the CIO to obtain it.

Chapter 2

The regulatory base: a funded architecture blueprint

2

The mille-feuille — PSD2, DORA, MiCA, AML-CFT — discourages by its thickness. Put in order, it converges on one question: can you prove that money and data go where they must, even on the day everything goes wrong?

2.1 PSD2: open banking, ten years on

T he second payment services directive brought two ideas into law: the account belongs to the client — licensed third parties may access it with their consent, via API, to initiate payments or aggregate data — and strong authentication is the norm, two factors among possession, knowledge, inherence. Ten years on, the operational record is mixed: the APIs exist everywhere, their quality varies enormously — availability rates, data freshness, consent journeys — and that is exactly where the competitive difference is decided.

The strategic reading: PSD2 was only the first stage. PSD3 and the FIDA regulation in preparation will extend access from payment data to broad financial data — savings, credit, insurance — with sharing and compensation schemes between actors. An institution whose PSD2 APIs are mediocre will approach open finance structurally late; a fintech that knows how to consume and expose these APIs cleanly already has its 2028 advantage. Chapter 5 returns to this.

The test that says it all. Ask your teams the real success rate of aggregator connections on your account APIs last month — not the contractual SLA, the measured rate. If it is not measured, you have your answer: your open banking is declarative.

2

Chapter 2 — The regulatory base FinTech & digital banking

2.2 DORA: resilience becomes a governance duty

DORA, in plain words. Digital Operational Resilience Act: European Regulation (EU) 2022/2554, adopted at the end of 2022, applicable since 17 January 2025 — directly, without national transposition. Its idea fits in one sentence: a financial entity must keep functioning during an outage or an attack, and be able to prove it to the supervisor . It concerns nearly all financial entities — banking, payments, insurance, asset management, crypto — and, by contractual ricochet, their IT providers. Sanctions can reach 2 % of worldwide annual turnover; 2026 is the first full year of supervision.

DORA changes less the techniques than the distribution of responsibilities. Five pillars:

IT risk management, carried explicitly by the management body — trained, informed, accountable. Incident management, with classification and notification of major incidents to the supervisor within short deadlines. Resilience testing, up to threat-led penetration tests for significant actors. Third-party risk : a complete information register of IT providers, mandatory contractual clauses, exit strategies for critical providers — and direct European oversight of the major cloud suppliers. Information sharing between peers, encouraged and framed.

The operational reading: DORA is your architecture's specification, written by the regulator. The provider register is your dependency map; the required tests are your chapter 6 exercises; the exit strategies are the reversibility this collection recommends in every contract. A DORA programme run as a compliance file produces binders; run as an architecture programme, it produces robustness — at the same price.

→

→

→

→

1

2

3

4

5

Governance

Incidents

Tests

Third parties

Sharing

IT risk carried by a trained management body

Classified, notified, capitalised

Of resilience — played, not declared

Register, contracts, exit

The threat is fought together

The newest point for many actors is pillar 4: your outsourcing chain becomes a regulatory object. The BaaS, the cloud, the payment processor, the KYC tool in SaaS: each must be in the register, under a compliant contract, with a practicable exit. Chapter 4 makes it a blind spot in its own right.

2

Chapter 2 — The regulatory base FinTech & digital banking

2.3 MiCA, AML-CFT: trust, on both sides

MiCA (Markets in Crypto-Assets) has made crypto-assets a regulated market: European licensing of providers (custody, exchange, advice), prudential and governance requirements, strict framing of stablecoins. The practical consequence for everyone — not only crypto actors: a crypto offer is now built like a banking product , with a licence or a licensed partner, product compliance and client information. The improvisation of 2021 is over; chapter 4 treats the case of the offer “under consideration” that already lives in fact.

AML-CFT. The fight against money laundering and terrorist financing is the oldest of the bases, and the most demanding day to day: customer due diligence at onboarding and over time, transaction monitoring, suspicious-activity reports, asset freezes. The European package under way — single rulebook, the AMLA authority — harmonises and hardens the whole. The architecture lesson is constant: an AML programme is worth what the client data feeding it is worth. Duplicates, outdated identities, untraced beneficial owners mechanically produce missed alerts and false positives that drown the teams — chapter 3, §3.4, makes it workstream no. 1.

What converges

Text

What it requires in its own right

What converges

PSD2 / PSD3

Strong authentication, account APIs, fraud liability

Four common demands: — the inventory (flows, providers, access) — mastery of identities and client data — tested resilience, a practicable exit — proof: logs, registers, exercises

DORA

Governed IT risk, third-party register, tests, notification

MiCA

Crypto licensing, stablecoin requirements, information

AML-CFT / GDPR

KYC, monitoring, reports; legal basis, minimisation, rights

The right-hand column is the reading key: one well-run programme serves all four compliances at once. The opposite — four files run separately — costs four times and protects nothing: the very definition of paper compliance.

And in Switzerland? Outside the European Union, the substance does not change — the labels do. FINMA supervises; operational resilience falls under the FINMA circular on operational risks and the banking ordinance (continuity plans, outsourcing, notification of cyberattacks); customer knowledge under the anti-money-laundering act and the CDB; personal data under the revised data-protection act (nFADP); financial services under FinSA/FinIA. The four common demands of the table — inventory, client data, tested resilience, proof — remain exactly the same: an institution active on both sides of the border can, and should, serve them with one programme.