Lecture 9: RegTech, Cybersecurity & Privacy-Preserving Compute

Industrialising compliance · cyber-threat landscape · ZKPs, MPC, federated learning · post-quantum

Prof. Dr. Andre Guettler Director of the Institute
Helmholtzstraße 22, Room 205
andre.guettler@uni-ulm.de
+49 731 50 31 030

Oliver Padmaperuma Doctoral Candidate
Helmholtzstraße 22, Room 203
oliver.padmaperuma@uni-ulm.de
+49 731 50 31 036

9.1 Course objectives

• 9.1 Course objectives
• 9.2 Recap from Lecture 8
• 9.3 RegTech overview
• 9.4 KYC/AML automation
• 9.5 Cybersecurity threats in finance
• 9.6 Privacy-preserving compute
• 9.7 Post-quantum cryptography
• 9.8 Conclusion of Lecture 9

• Welcome to
• Course Objective
• Course at a glance (1/3)
• Course at a glance (2/3)
• Course at a glance (3/3)
• Assignments / Exams

Welcome to Emerging Technology & Finance

• This is a flipped-classroom Bachelor course: every regular lecture (odd weeks) is followed by a flipped session (even weeks) where all groups present on the same topic. There is no exam to register for — sign up on the course Moodle page by 15 October 2026 so you receive announcements and the token-allocation quiz links.
• Form a group of 4 by the end of Week 1 (Moodle sign-up sheet). Stragglers will be allocated by the lecturers.
• Grading is 100% cumulative across the 6 flipped sessions: each session = 50% peer-allocated tokens + 50% lecturer evaluation. Each group gets 20 fresh tokens every flipped week to allocate to other groups via a Moodle quiz within 5 minutes of the session ending.
• Submission per session: upload your slide PDF to Moodle before each flipped session starts. Ask questions during or right after each session — that is the preferred channel.
• Admin / studies / exam-eligibility questions go to the registrar’s office (Studiensekretariat) at studiensekretariat@uni-ulm.de.
• Course-content questions outside class: email oliver.padmaperuma@uni-ulm.de, CC andre.guettler@uni-ulm.de.
• We also recommend the student advisory service.

Course Objective

Scope

We will:

• Survey six emerging-technology modules at the cutting edge of finance: agentic AI · blockchain & DeFi · fintech business models · RegTech & cybersecurity · CBDCs
• Pair every regular lecture with a flipped session in which every group presents their angle on the topic
• Train critical evaluation, presentation, and peer-judgment skills via a transparent token-based peer-grading mechanic
• Place the technologies in a real-world business and regulatory context (PSD2/3, MiCA, EU AI Act, post-quantum standards)

We will NOT:

• Build production-grade fintech systems or trade live capital
• Cover deep technical implementations (we treat code as supplement, not core)
• Run a separate written exam or final-pitch competition — the cumulative flipped-session grade is the entire grade

Approach

Flipped-classroom alternation (12 weeks)

• Odd weeks (W1, W3, W5, W7, W9, W11): regular lecture introducing the topic
• Even weeks (W2, W4, W6, W8, W10, W12): flipped session — all groups present and allocate tokens
• Groups of 4, formed by end of Week 1

Token mechanic (the grading vehicle)

• 20 tokens per group per flipped session
• Each group allocates them to other groups, weighing insight · originality · clarity · critical depth
• Cumulative across 6 sessions = 50% of final grade · lecturer evaluation = 50%

Course at a glance (1/3)

Foundations of Digital Disruption in Financial Services

Week 1

22.10.2026

What is ‘emerging tech in finance’, how did we get here, where is it going

• Three waves of digital disruption in finance
• Today’s actors: incumbents, challengers, Big Tech, infrastructure
• Regulatory backdrop: PSD2, MiCA, EU AI Act
• Why now: structural drivers
• What this course will cover

Flipped — Digital Disruption in Financial Services

Week 2

29.10.2026

Group presentations · token allocation · discussion

• Recap of the foundations lecture
• Group presentations on digital disruption
• Token allocation & next steps

Agentic AI & LLMs in Finance

Week 3

05.11.2026

From LLMs to agents · applications · failure modes · EU AI Act

• LLMs in finance: architecture, training, capabilities
• Agentic AI: from answers to actions
• Applications: RAG, robo-advisors, AML, trading agents
• Failure modes: hallucination, drift, prompt injection
• Governance: EU AI Act and high-risk obligations

Flipped — Agentic AI & LLMs in Finance

Week 4

12.11.2026

Group presentations · token allocation · discussion

• Recap of the agentic AI lecture
• Group presentations on real LLM and agent deployments
• Token allocation & next steps

Blockchain, Crypto, DeFi & Tokenisation

Week 5

19.11.2026

From distributed ledgers to MiCA-regulated markets

• Blockchain primer: ledgers, consensus, smart contracts
• Crypto markets: BTC, ETH, stablecoins
• DeFi primitives: AMMs, lending, derivatives
• Tokenisation of real-world assets
• MiCA framework and EU enforcement

Course at a glance (2/3)

Flipped — Blockchain, Crypto, DeFi & Tokenisation

Week 6

26.11.2026

Group presentations · token allocation · discussion

• Recap of the blockchain & DeFi lecture
• Group presentations on real protocols and deployments
• Token allocation & next steps

Fintech Business Models

Week 7

03.12.2026

Neobanks, embedded finance, BNPL, Open Banking, Big Tech in finance

• Neobanks: N26, Revolut, Monzo, Chime
• Embedded finance & BaaS
• BNPL: Klarna, Affirm, regulatory pushback
• Open Banking & PSD2 outcomes
• Big Tech in finance

Flipped — Fintech Business Models

Week 8

10.12.2026

Neobanks, embedded finance, BNPL · group presentations · token allocation

• Recap of the fintech business-models lecture
• Group presentations on real companies and unit economics
• Token allocation & next steps

RegTech, Cybersecurity & Privacy-Preserving Compute

Week 9

17.12.2026

Industrialising compliance · cyber-threat landscape · ZKPs, MPC, federated learning · post-quantum

• RegTech overview: industrialising compliance
• KYC/AML automation in production
• Cybersecurity threats in finance
• Privacy-preserving compute: ZKPs, MPC, federated learning
• Post-quantum cryptography & the migration

Flipped — RegTech, Cybersecurity & Privacy-Preserving Compute

Week 10

07.01.2027

Group presentations · token allocation · discussion

• Recap of the RegTech & security lecture
• Group presentations on vendors, incidents, and emerging tech
• Token allocation & next steps

Course at a glance (3/3)

CBDCs & the Future of Money

Week 11

14.01.2027

Wholesale vs retail design · Digital Euro · e-CNY · programmable money

• What’s a CBDC: wholesale vs retail
• The Digital Euro state of play
• China’s e-CNY and small-country implementations
• Programmable money: feature, threat, or both
• Stablecoins as private money: tension with CBDCs

Flipped — CBDCs & the Future of Money

Week 12

21.01.2027

Final session · group presentations · token allocation · course wrap-up

• Recap of the CBDCs lecture
• Group presentations on real CBDC projects
• Token allocation, final standings, and course retrospective

Assignments / Exams

Flipped-Classroom Presentation Series 100% of your grade

Six in-class group presentations across six emerging-tech topics, graded cumulatively. Each session: 50% peer-allocated tokens + 50% lecturer evaluation.

Group of up to 4.

Submit by emailing oliver.padmaperuma@uni-ulm.de, CC andre.guettler@uni-ulm.de. Subject pattern: Emerging Technology & Finance_assignment-1-flipped-classroom-presentations_surname1_surname2_…

21 January 2027

9.2 Recap from Lecture 8

• 9.1 Course objectives
• 9.2 Recap from Lecture 8
• 9.3 RegTech overview
• 9.4 KYC/AML automation
• 9.5 Cybersecurity threats in finance
• 9.6 Privacy-preserving compute
• 9.7 Post-quantum cryptography
• 9.8 Conclusion of Lecture 9

• What the flipped session surfaced

What the flipped session surfaced

• The neobank unit-economics that convinced the room — usually Revolut’s 2024 profitability transition or N26’s path to operating profit.
• The BNPL regulatory-recharacterisation pattern: provider response varies sharply by jurisdiction.
• Whether PSD2 has delivered the competition it promised — the cohort’s typical conclusion: yes at the infrastructure layer, no at the retail layer.

The Week-8 flipped session was the last one before the Christmas break — the next session is six weeks away. Use the break to read ahead: the Lecture-10 flipped session is dense, covers privacy-preserving compute that you will not have seen before, and the strongest groups will arrive with real evidence. Today’s lecture pivots from what fintechs build to what fintechs are obligated to do — the compliance perimeter and the post-quantum-deadline curtain that’s about to fall on it. RegTech is the unglamorous corner of fintech, but it’s where the regulatory-technology dollar share is growing fastest in 2026.

9.3 RegTech overview

• 9.1 Course objectives
• 9.2 Recap from Lecture 8
• 9.3 RegTech overview
• 9.4 KYC/AML automation
• 9.5 Cybersecurity threats in finance
• 9.6 Privacy-preserving compute
• 9.7 Post-quantum cryptography
• 9.8 Conclusion of Lecture 9

• What RegTech is, what it isn’t
• The four buckets of RegTech

What RegTech is, what it isn’t

• Is — using technology to industrialise the compliance function: KYC, AML, transaction monitoring, regulatory reporting, conduct surveillance, operational-resilience testing.
• Isn’t — just buying a vendor’s “AI” claim. Most “RegTech” products are rule engines with a UI; substantive AI in compliance is rarer than marketing implies.
• Why now — regulatory volume has outpaced manual scaling; cumulative AML fines crossed $50B globally; DORA, AI Act, MiCA all add reporting load simultaneously.

RegTech as a category has two narratives running in parallel: the substantive one (genuine automation of previously-manual workflows like SAR drafting or DORA incident reporting) and the rebranding one (existing rule engines repackaged as “AI compliance”). Cite Arner, Barberis, and Buckley (2017) — Arner, Barberis, and Buckley’s piece is the foundational framing of why technology and regulation co-evolve. The interesting question for the next 5 years is which RegTech category will be standardised at the regulator level — i.e. which compliance workflows will become regulator-published reference implementations that all banks can adopt, rather than competitive vendor markets.

The four buckets of RegTech

• KYC document parsing (Onfido, Jumio)
• Biometric verification
• Sanctions-list matching
• Beneficial-ownership graphs (Sayari, KYC2020)

• AML rule engines (Actimize, Quantexa)
• Behavioural anomaly detection (Featurespace, Feedzai)
• Chainalysis / TRM Labs for crypto
• Cross-product fraud detection

• SAR (Suspicious Activity Report) generation
• MiFID II transaction reporting (Cappitech, Kaizen)
• DORA incident-reporting workflows
• Regulatory data-lake queries (Suade, Vermeg)

• Trader-chat surveillance (Behavox, Steel Eye)
• Best-execution monitoring
• Market-abuse pattern detection
• Voice-call transcription + classification

The four buckets divide the RegTech market by workflow rather than by technology — which is the right framing for buyers. Banks don’t buy “AI”; they buy “AML transaction monitoring” or “DORA incident reporting.” Inside each bucket, the technology mix is heterogeneous: identity & onboarding leans on OCR + computer vision; transaction monitoring runs hybrid rule + ML pipelines; reporting is mostly ETL with audit logging; conduct surveillance has the most genuine NLP. When students research vendors for Week-10 presentations, asking which bucket the vendor serves is the most useful first cut (Arner, Barberis, and Buckley 2017).

9.4 KYC/AML automation

• 9.1 Course objectives
• 9.2 Recap from Lecture 8
• 9.3 RegTech overview
• 9.4 KYC/AML automation
• 9.5 Cybersecurity threats in finance
• 9.6 Privacy-preserving compute
• 9.7 Post-quantum cryptography
• 9.8 Conclusion of Lecture 9

• The AML production reality
• Failure modes in AML AI

The AML production reality

• Banks generate millions of transaction alerts per year; about 5–10% survive triage to investigation; a fraction of 1% result in a Suspicious Activity Report (SAR); even fewer trigger enforcement.
• False-positive cost is the dominant operational expense — investigator time is the binding constraint.
• AI’s promise: reduce false positives without missing true positives. Evidence so far: mixed, with measurable gains in specific deployments and new failure modes in others.

The AML system globally is, by its own metrics, very inefficient — fewer than 0.1% of alerts produce enforcement outcomes, and most launderers route around the controls anyway. The temptation is to declare it broken; the realistic view is that it serves as a deterrence and audit-trail function more than a detection function. AI’s role here is to make the audit trail cheaper per alert, not to dramatically improve true-positive yield — though specific deployments (Featurespace at NatWest, Quantexa at HSBC) have published modest gains (Arner, Barberis, and Buckley 2017).

Failure modes in AML AI

• Concept drift — money-laundering typologies evolve; static models degrade quickly.
• Demographic bias — flagging models can systematically over-flag specific customer segments (regulators have brought enforcement here).
• Explanation quality — investigators must defend why a transaction was flagged in court; opaque models limit this.
• Adversarial structuring — sophisticated launderers learn to stay just under model thresholds.

The most consequential failure mode of AML AI is the one that doesn’t look like failure: demographic over-flagging. If a model is technically accurate but disproportionately flags customers from one nationality, religion, or income segment, the bank is operationally exposed even when the model is statistically correct. The FCA and ACPR have both brought enforcement actions on this between 2022 and 2024. The implication for governance is that bias testing must be a continuous monitoring activity, not a one-off model-validation step. Cite Arner, Barberis, and Buckley (2017).

9.5 Cybersecurity threats in finance

• 9.1 Course objectives
• 9.2 Recap from Lecture 8
• 9.3 RegTech overview
• 9.4 KYC/AML automation
• 9.5 Cybersecurity threats in finance
• 9.6 Privacy-preserving compute
• 9.7 Post-quantum cryptography
• 9.8 Conclusion of Lecture 9

• The 2026 threat landscape
• DORA: what changes for EU finance

The 2026 threat landscape

• State-sponsored APT actors — Lazarus (DPRK), FIN7, APT41 — targeted credential theft, SWIFT-network fraud, cryptocurrency exchange compromise.
• Ransomware — financial services is the second-most-targeted sector; ICBC’s 2023 ransomware incident is the canonical recent case.
• Supply-chain attacks — SolarWinds (2020), MOVEit (2023), 3CX (2023). One vendor compromise affects hundreds of banks.
• Insider threats — under-reported but persistently material; cumulative losses likely exceed external-attack losses.

The cyber threat landscape in 2026 is defined by industrialisation: the major attack categories all run as professional operations with division of labour, malware-as-a-service marketplaces, and persistent infrastructure. The mismatch is that most banks’ defensive structures still resemble 2010-era organisations (security as a department, not a continuous function). The supply-chain attack category is the most consequential for banks because they don’t directly control the attack surface — a vendor compromise (Okta, MOVEit, SolarWinds) propagates to everyone using that vendor. This is the structural reason DORA exists: regulators forcing banks to inventory and supervise their third-party-ICT risk because the banks weren’t doing it themselves.

DORA: what changes for EU finance

• In force January 2025 for EU financial entities (banks, insurers, investment firms, crypto-asset service providers).
• Four pillars:
  1. ICT-risk management — board-level oversight, documented policies.
  2. Incident reporting — major incidents reported to the national competent authority within 4 hours.
  3. Operational-resilience testing — annual stress tests, threat-led penetration testing for critical entities.
  4. Third-party (ICT-vendor) risk oversight — contractual obligations on cloud providers, audit rights, exit-plan requirements.
• Designation of critical ICT third-party providers — direct EU supervision of major cloud providers (AWS, Azure, Google Cloud) in their financial-services capacity.

DORA’s most consequential clause is the direct supervision of critical ICT third-party providers — for the first time, EU regulators have authority to inspect, fine, and ultimately exclude major cloud providers if they fail their financial-services obligations. This is a structural shift comparable to the AI Act in scale: it doesn’t just impose obligations on the regulated banks, it extends the regulatory perimeter to their tech-stack suppliers. Bring a specific DORA-response example (e.g. a bank’s annual report disclosure on DORA preparation) to Week-10 presentations if you cover this angle. Cite the regulation text directly (Arner, Barberis, and Buckley 2017 for the broader framing).

9.6 Privacy-preserving compute

• 9.1 Course objectives
• 9.2 Recap from Lecture 8
• 9.3 RegTech overview
• 9.4 KYC/AML automation
• 9.5 Cybersecurity threats in finance
• 9.6 Privacy-preserving compute
• 9.7 Post-quantum cryptography
• 9.8 Conclusion of Lecture 9

• Three primitives, three use cases
• The deployment honesty check

Three primitives, three use cases

• Prove a fact without revealing the underlying data.
• Use: zkKYC (prove a customer is over 18 / not sanctioned without sharing PII).
• Foundation: Goldwasser, Micali, and Rackoff (1989).
• Production: zkRollups for scaling; zkKYC mostly pilot.

• Compute a function over inputs no party reveals to others.
• Use: cross-bank fraud detection without sharing customer data.
• Production examples: Visa cross-issuer fraud, JPM internal pilots.

• Train a model on data that never leaves devices or institutions.
• Use: phone-keyboard prediction (Google Gboard); inter-bank AML pilots.
• Foundation: McMahan et al. (2017).

The three primitives serve overlapping but distinct goals: ZKPs prove a fact, MPC computes a function, and federated learning trains a model. Vendors and journalists routinely conflate them; vendors because the conflation sells more product, journalists because the underlying maths is unfamiliar. For a Bachelor finance audience, the takeaway is to be skeptical of marketing claims like “privacy-preserving AI” until the specific primitive and threat model are named. The cryptographic guarantee in each case is precisely what is hidden from whom, and that varies sharply across primitives (Goldwasser, Micali, and Rackoff 1989; McMahan et al. 2017).

The deployment honesty check

• ZKPs in zkRollups — Polygon zkEVM, Starknet, zkSync — scaling, not privacy.
• Federated learning in mobile keyboards (Google Gboard, Apple QuickType).
• Limited MPC pilots in inter-bank fraud (Visa cross-issuer, JPM Liink).

• True zkKYC at production scale.
• Cross-bank MPC across regulatory regimes (national-FIU coordination).
• Privacy-preserving general analytics in production (e.g. private credit scoring).

Privacy-preserving compute has been “five years away” for twenty-five years. Some primitives finally deploy at scale in 2024–26 — but the financial-services applications mostly remain pilots. Be honest about this gap in Week-10 presentations: a vendor’s “privacy-preserving AI” product is far more likely to be a federated-learning pilot than a production zkKYC deployment. When evaluating a deployment, ask: what is the cryptographic guarantee, who provides it, and what evidence is there that it scales? Most pilots fail the third question.

9.7 Post-quantum cryptography

• 9.1 Course objectives
• 9.2 Recap from Lecture 8
• 9.3 RegTech overview
• 9.4 KYC/AML automation
• 9.5 Cybersecurity threats in finance
• 9.6 Privacy-preserving compute
• 9.7 Post-quantum cryptography
• 9.8 Conclusion of Lecture 9

• Why now
• What banks must do

Why now

• A cryptographically-relevant quantum computer could break RSA, ECDSA, and Diffie-Hellman — the primitives underpinning HTTPS, SWIFT, payment-card cryptography, and key exchange across most banking infrastructure.
• “Harvest now, decrypt later” — adversaries are already collecting encrypted financial traffic, anticipating future decryption.
• NIST published its first post-quantum cryptographic standards in 2024 (National Institute of Standards and Technology 2024) — most notably FIPS 203 (ML-KEM) for key encapsulation.

The deadline isn’t when quantum computers can break crypto — it is when long-lived secrets become decryptable retroactively. That deadline has effectively passed.

The “harvest now, decrypt later” threat is the easiest part of post-quantum cryptography for a Bachelor audience to grasp and the part most often overlooked. Adversaries record encrypted financial communications today, hoping to decrypt them in 10–20 years when quantum computers mature. For long-secret data (multi-decade contracts, KYC identity tokens, long-term certificates), the threat is not future — it is retroactive. NIST’s FIPS 203 publication in 2024 is the starting gun for migration; well-prepared banks began migration planning in 2022–23, others are starting in 2025–26 (National Institute of Standards and Technology 2024).

What banks must do

• Inventory all cryptographic deployments — most banks don’t yet have a complete one.
• Crypto-agility — design systems so primitives can be swapped without re-architecting.
• Migration sequencing — start with long-secret data (multi-year contracts, identity tokens, root-of-trust certificates).
• Vendor coordination — payment networks (Visa, Mastercard), SWIFT, and cloud providers must all migrate; bank’s effort is meaningless if its rails don’t migrate too.

Most banks’ published timelines: PQC migration substantially complete by 2030, fully complete by 2033. Expect slippage.

Walk through a concrete bank’s published migration plan if you cover this in Week-10 — HSBC’s Quantum-Safe pilot, JPMorgan’s PQC roadmap, BIS Innovation Hub Project Leap. The honest framing is that crypto-agility is the deliverable that actually matters: rather than migrating to a specific PQC algorithm, banks should build infrastructure that lets them swap algorithms in 6 months when the next vulnerability is found or the next standard arrives. The 2024–28 phase is largely crypto-agility work; the 2028–33 phase is the actual PQC rollout. Cite National Institute of Standards and Technology (2024).

9.8 Conclusion of Lecture 9

• 9.1 Course objectives
• 9.2 Recap from Lecture 8
• 9.3 RegTech overview
• 9.4 KYC/AML automation
• 9.5 Cybersecurity threats in finance
• 9.6 Privacy-preserving compute
• 9.7 Post-quantum cryptography
• 9.8 Conclusion of Lecture 9

• Course at a glance (1/3)
• Course at a glance (2/3)
• Course at a glance (3/3)
• Further reading
• Prepare before next flipped session (Week 10)
• See you next time
• References

Course at a glance (1/3)

Foundations of Digital Disruption in Financial Services

Week 1

22.10.2026

What is ‘emerging tech in finance’, how did we get here, where is it going

• Three waves of digital disruption in finance
• Today’s actors: incumbents, challengers, Big Tech, infrastructure
• Regulatory backdrop: PSD2, MiCA, EU AI Act
• Why now: structural drivers
• What this course will cover

Flipped — Digital Disruption in Financial Services

Week 2

29.10.2026

Group presentations · token allocation · discussion

• Recap of the foundations lecture
• Group presentations on digital disruption
• Token allocation & next steps

Agentic AI & LLMs in Finance

Week 3

05.11.2026

From LLMs to agents · applications · failure modes · EU AI Act

• LLMs in finance: architecture, training, capabilities
• Agentic AI: from answers to actions
• Applications: RAG, robo-advisors, AML, trading agents
• Failure modes: hallucination, drift, prompt injection
• Governance: EU AI Act and high-risk obligations

Flipped — Agentic AI & LLMs in Finance

Week 4

12.11.2026

Group presentations · token allocation · discussion

• Recap of the agentic AI lecture
• Group presentations on real LLM and agent deployments
• Token allocation & next steps

Blockchain, Crypto, DeFi & Tokenisation

Week 5

19.11.2026

From distributed ledgers to MiCA-regulated markets

• Blockchain primer: ledgers, consensus, smart contracts
• Crypto markets: BTC, ETH, stablecoins
• DeFi primitives: AMMs, lending, derivatives
• Tokenisation of real-world assets
• MiCA framework and EU enforcement

Course at a glance (2/3)

Flipped — Blockchain, Crypto, DeFi & Tokenisation

Week 6

26.11.2026

Group presentations · token allocation · discussion

• Recap of the blockchain & DeFi lecture
• Group presentations on real protocols and deployments
• Token allocation & next steps

Fintech Business Models

Week 7

03.12.2026

Neobanks, embedded finance, BNPL, Open Banking, Big Tech in finance

• Neobanks: N26, Revolut, Monzo, Chime
• Embedded finance & BaaS
• BNPL: Klarna, Affirm, regulatory pushback
• Open Banking & PSD2 outcomes
• Big Tech in finance

Flipped — Fintech Business Models

Week 8

10.12.2026

Neobanks, embedded finance, BNPL · group presentations · token allocation

• Recap of the fintech business-models lecture
• Group presentations on real companies and unit economics
• Token allocation & next steps

RegTech, Cybersecurity & Privacy-Preserving Compute

Week 9

17.12.2026

Industrialising compliance · cyber-threat landscape · ZKPs, MPC, federated learning · post-quantum

• RegTech overview: industrialising compliance
• KYC/AML automation in production
• Cybersecurity threats in finance
• Privacy-preserving compute: ZKPs, MPC, federated learning
• Post-quantum cryptography & the migration

Flipped — RegTech, Cybersecurity & Privacy-Preserving Compute

Week 10

07.01.2027

Group presentations · token allocation · discussion

• Recap of the RegTech & security lecture
• Group presentations on vendors, incidents, and emerging tech
• Token allocation & next steps

Course at a glance (3/3)

CBDCs & the Future of Money

Week 11

14.01.2027

Wholesale vs retail design · Digital Euro · e-CNY · programmable money

• What’s a CBDC: wholesale vs retail
• The Digital Euro state of play
• China’s e-CNY and small-country implementations
• Programmable money: feature, threat, or both
• Stablecoins as private money: tension with CBDCs

Flipped — CBDCs & the Future of Money

Week 12

21.01.2027

Final session · group presentations · token allocation · course wrap-up

• Recap of the CBDCs lecture
• Group presentations on real CBDC projects
• Token allocation, final standings, and course retrospective

Further reading

• Arner, Barberis, and Buckley (2017) — the canonical RegTech framing paper.
• Goldwasser, Micali, and Rackoff (1989) — the foundational ZKP paper; read for the intuition of interactive proofs.
• McMahan et al. (2017) — federated learning; read sections 1–3 for the mechanics.
• National Institute of Standards and Technology (2024) — FIPS 203 (abstract only — the standard itself is for implementers).

Prepare before next flipped session (Week 10)

Note: Lecture 9 is the last session before the Christmas break. The Week-10 flipped session runs on 7 January 2027 — use the break to prep thoroughly.

1. Pick your Week-10 angle from the presentation series brief.
2. Bring measurable evidence — incident impact ($), false-positive rates, audit findings, regulator statements.
3. Distinguish deployed products from research pilots — this is the single most common Week-10 failure mode.
4. Upload slide PDF to Moodle before 14:00 on 7 January.

See you next time

Reminder

• Next session: Lecture 10 — Flipped: RegTech, Cybersecurity & Privacy-Preserving Compute on 7 January 2027 (after Christmas break).
• Each group presents (6 min + 2 min Q&A).
• Slides due on Moodle before 14:00.

References

Arner, Douglas W., János Barberis, and Ross P. Buckley. 2017. “FinTech, RegTech, and the Reconceptualization of Financial Regulation.” Northwestern Journal of International Law & Business 37 (3): 371–413.

Goldwasser, Shafi, Silvio Micali, and Charles Rackoff. 1989. “The Knowledge Complexity of Interactive Proof Systems.” SIAM Journal on Computing 18 (1): 186–208. https://doi.org/10.1137/0218012.

McMahan, Brendan, Eider Moore, Daniel Ramage, Seth Hampson, and Blaise Aguera y Arcas. 2017. “Communication-Efficient Learning of Deep Networks from Decentralized Data.” In Proceedings of the 20th International Conference on Artificial Intelligence and Statistics (AISTATS), 1273–82.

National Institute of Standards and Technology. 2024. “FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard.” U.S. Department of Commerce, NIST FIPS Publication 203. https://csrc.nist.gov/pubs/fips/203/final.