Lecture 9: RegTech, Cybersecurity & Privacy-Preserving Compute
Industrialising compliance · cyber-threat landscape · ZKPs, MPC, federated learning · post-quantum
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 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
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
Group presentations · token allocation · discussion
- Recap of the foundations lecture
- Group presentations on digital disruption
- Token allocation & next steps
Agentic AI & LLMs in Finance
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
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
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
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
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
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
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
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
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
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
- 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.
Notes
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
- 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.
Notes
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
Notes
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
- 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.
Notes
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.
Notes
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
- 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.
Notes
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:
- ICT-risk management — board-level oversight, documented policies.
- Incident reporting — major incidents reported to the national competent authority within 4 hours.
- Operational-resilience testing — annual stress tests, threat-led penetration testing for critical entities.
- 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.
Notes
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
- 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).
Notes
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).
Notes
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
- 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.
Notes
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.
Notes
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)
Foundations of Digital Disruption in Financial Services
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
Group presentations · token allocation · discussion
- Recap of the foundations lecture
- Group presentations on digital disruption
- Token allocation & next steps
Agentic AI & LLMs in Finance
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
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
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
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
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
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
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
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
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
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.
- Pick your Week-10 angle from the presentation series brief.
- Bring measurable evidence — incident impact ($), false-positive rates, audit findings, regulator statements.
- Distinguish deployed products from research pilots — this is the single most common Week-10 failure mode.
- Upload slide PDF to Moodle before 14:00 on 7 January.
See you next time
- 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.