RR Skillverse Module 7 of 12 Theory Handbook Finance + AI + Privacy

Module 7 — Federated & Privacy-Preserving ML

Same theory-first structure as Modules 1–6: for every technique below, what it is, why it exists — the specific problem it was invented to solve — what else you could use instead, and a real financial example. Every module so far has assumed RR Finance's training data lives in one place. Module 7 removes that assumption: what if the data can never actually be centralized at all?

⬇ Download the Module 7 notebook ← Back to Module 6 All modules →

Recap — what RR Finance already has

Module 7 is not a fresh start. Here's exactly what it inherits before removing the centralized-data assumption.

MODULE 1–2

A validated logistic-regression baseline and a deeper ANN, both trained on one centralized CSV — the assumption this module removes.

MODULE 1

Data poisoning and an Isolation Forest defence — the row-level version of the aggregation-layer attack this module introduces.

MODULE 6

SHAP, LIME, counterfactuals, and a real age-fairness audit — all computed on a centrally-trained model. This module asks whether that audit still holds once training changes.

What's new in Module 7

Every prior module assumed RR Finance's 800 rows sit in one place. Module 7 asks what still works when that single CSV is really five institutions' private data, none of which can or will hand over their raw records — and what new risks appear once training itself becomes distributed.

Why the data can't move

Real cross-institution credit modelling runs into a wall no algorithm can fix by being smarter: the data is not allowed to leave.

The legal/commercial reality

Data residency rules, privacy law, and competitive confidentiality between lending institutions mean raw applicant records often cannot be centralized, no matter how much better the resulting model would be.

The federated answer

Move the MODEL to the data instead of the data to the model — train locally at each institution, share only the resulting weight updates.

Why new attack surfaces follow

A server that trusts every institution's returned update equally, and a model whose weights alone might still leak information about individual applicants, are two NEW risks this module confronts directly.

CONCEPT 1

Why Federated Learning

Moving the model to the data, instead of the data to the model.

Overview

🧮 Math & Algorithm

What it is

Federated Learning trains one shared model across data that lives at multiple separate locations ("clients" or, for RR Finance, partner institutions), without any of them sending their raw data anywhere else. Each institution trains locally; only the resulting model updates ever travel.

Why it exists — the history

2016–2017

McMahan et al., Google, "Communication-Efficient Learning of Deep Networks from Decentralized Data" introduced federated learning to train models across millions of mobile phones' keyboards without uploading anyone's typed messages to a central server — the same core idea RR Finance applies here across institutions instead of phones.

✓ Use it when

Data residency law, competitive confidentiality, or privacy regulation prevents centralizing training data across institutions
Each participant has enough local data to contribute a meaningful, non-trivial local training update

✗ Reach for something else when

Centralizing the data is actually permitted and simpler — federation adds real complexity (communication rounds, aggregation, new attack surfaces) that a centralized pipeline (Modules 1–6) simply doesn't need

REAL-WORLD FINANCIAL EXAMPLE

Five partner lenders each hold their own applicants' records under strict confidentiality agreements. None can send RR Finance a single row of raw data — but all five can run a local training loop and send back model weights, which is exactly what this module builds.

⬇ Run this lesson in the notebook

No formula in this framing lesson — it sets up the client/server structure (Concept 2) and the new attack surfaces (Concepts 4–5) the rest of this module addresses directly.

CONCEPT 2

Federated Averaging (FedAvg)

The foundational algorithm: train locally, average globally, repeat.

Overview

🧮 Math & Algorithm

What it is

FedAvg is the core federated learning algorithm: each communication round, every client trains the current global model on its own local data for a few epochs, then the server collects every client's resulting weights and averages them to produce the next global model.

Why it exists — the history

2017

Introduced in the same McMahan et al. paper as Concept 1 — the specific insight was that AVERAGING MODEL WEIGHTS across clients, rather than averaging gradients every single step, dramatically reduces how often clients and server need to communicate, which matters enormously when "clients" are slow, unreliable network connections (or, here, separate institutions).

✓ What the notebook demonstrates

A working FedAvg loop across 5 simulated RR Finance institutions, reaching test accuracy comparable to — in this run, even slightly ahead of — a centralized benchmark trained on all the same data in one place

✗ What FedAvg does NOT guarantee on its own

Privacy (Concept 4 adds that) or robustness to a malicious participant (Concepts 5–6 address that) — plain FedAvg only solves the "don't centralize the data" problem

REAL-WORLD FINANCIAL EXAMPLE

The notebook's federated model, trained across 5 simulated institutions with each institution's raw data staying local, reaches essentially the same test AUC as a fully centralized version trained on the identical rows all in one place.

⬇ Run this lesson in the notebook

w_(t+1) = Σₖ (nₖ/n) · wₖ_(t+1)

w_(t+1) is the new global model's weights after round t; k indexes each client (institution).

wₖ_(t+1) is client k's weights after training locally, starting from the CURRENT global model, for a few local epochs.

nₖ/n weights each client's contribution by its share of the total training data (n = total rows across all clients) — equal-sized clients, as simulated in this notebook, reduce this to a simple unweighted mean.

CONCEPT 3

The Non-IID Challenge

FedAvg's convenient assumption, and what breaks when it's false.

Overview

🧮 Math & Algorithm

What it is

FedAvg's simple averaging works best when every client's local data looks statistically similar to every other client's — an IID (independent and identically distributed) assumption. Real institutions rarely satisfy this: a regional branch, or a partner lender specializing in one credit tier, has data that looks systematically DIFFERENT from another institution's.

Why it exists — the history

Identified in the original 2017 FedAvg paper itself

McMahan et al. already reported accuracy degradation under non-IID client data splits; it has remained an active federated-learning research area since, because real deployments are essentially always non-IID to some degree.

✓ What the notebook demonstrates

A REAL non-IID split — institutions partitioned by sorted credit_score, so each one genuinely specializes in one tier — measurably underperforming the IID split from Concept 2

✗ An honest limitation, stated plainly

The measured gap here is modest, not catastrophic, because 5 institutions with mild specialization is a small-scale, low-heterogeneity example — real deployments with more clients and more extreme specialization see substantially larger degradation

REAL-WORLD FINANCIAL EXAMPLE

If one RR Finance partner institution serves almost exclusively prime borrowers and another almost exclusively subprime, naively averaging their locally-trained models pulls the global model away from what either institution's own applicants actually need — a real, measured cost of realistic institutional specialization.

⬇ Run this lesson in the notebook

No new aggregation formula — Concept 2's FedAvg update is unchanged. What changes is the statistical assumption behind it: FedAvg's convergence guarantees (in the original paper's analysis) rely on client data distributions being similar; non-IID splits violate that assumption, which shows up empirically as slower convergence and a lower final accuracy, exactly as measured in the notebook.

CONCEPT 4

Differential Privacy (DP-SGD)

A mathematical guarantee, not just a best-effort defence, on what one applicant's data could reveal.

Overview

🧮 Math & Algorithm

What it is

Differential Privacy bounds exactly how much any single training example could have changed the trained model — quantified by a privacy budget ε (epsilon). DP-SGD achieves this during neural network training by clipping each example's gradient contribution and adding calibrated random noise before every optimizer step.

Why it exists — the history

2006 → 2016

Dwork et al., 2006 formalised differential privacy as a mathematical definition, not a specific algorithm. Abadi et al. (Google), 2016, "Deep Learning with Differential Privacy" adapted it specifically to neural network training via per-example gradient clipping plus Gaussian noise — DP-SGD, implemented in this notebook using the real, widely-used opacus library.

✓ Use it when

Federation alone (Concept 2) keeps raw data local, but the TRAINED MODEL itself must also carry a provable guarantee against leaking whether any specific applicant was in the training set

✗ Watch out for

Privacy is not free — the notebook measures a REAL accuracy cost that grows as ε shrinks (stronger privacy); on this small, 800-row dataset the effect is somewhat noisy run-to-run, since DP's injected noise is more visible relative to a small dataset's signal

REAL-WORLD FINANCIAL EXAMPLE

The notebook trains the same classifier at five different privacy budgets and measures the real test-AUC cost of each — turning "how much privacy costs" from a theoretical question into an actual number RR Finance's governance function could put in a model card.

⬇ Run this lesson in the notebook

Pr[M(D) ∈ S] ≤ e^ε · Pr[M(D′) ∈ S] + δ

M is the training mechanism (DP-SGD); D and D′ are two datasets differing in exactly one applicant's record.

ε (epsilon) bounds how much the PROBABILITY of any outcome can differ depending on whether that one applicant's record was included — smaller ε means a tighter bound, i.e. stronger privacy.

δ (delta) is a small allowed probability that the ε-guarantee fails entirely — kept very small (1e-5 in the notebook) by convention.

DP-SGD's mechanism, concretely: clip each example's gradient to a maximum norm (max_grad_norm), then add Gaussian noise calibrated to that clipping bound before every optimizer step — the clipping bounds any one example's maximum influence, and the noise is what actually produces the formal (ε, δ) guarantee.

CONCEPT 5

Model Poisoning at the Aggregation Layer

Module 1 poisoned the data. This poisons the UPDATE instead.

Overview

🧮 Math & Algorithm

What it is

Module 1 demonstrated data poisoning — corrupting training rows before centralized training. Federated learning opens a related but distinct attack surface: one participating institution can send a corrupted or malicious MODEL UPDATE instead of real locally-trained weights — a Byzantine fault, borrowing the term from distributed-systems literature for a participant that can fail or misbehave in an arbitrary way.

Why it exists — the history

A direct consequence of federation's own design

The server in a federated system never sees any client's raw data or training process — only the returned weights. That is precisely what makes federation privacy-preserving, and precisely what makes a corrupted or malicious update hard to detect from the outside, unlike Module 1's poisoned rows, which a defender could in principle inspect directly.

✓ What the notebook demonstrates

A real, working attack: one institution (out of 5) returns a massively scaled, sign-flipped update instead of its real weights, and naive mean aggregation (Concept 2) has no mechanism to notice or resist it — a measured accuracy drop, not a hypothetical one

✗ What this is NOT

A claim that any real institution WOULD do this — the point is that the server's aggregation rule alone has to be robust to the possibility, since it cannot verify what happened inside any institution's own training loop

REAL-WORLD FINANCIAL EXAMPLE

A compromised or malfunctioning partner institution's server could corrupt the shared RR Finance model for every OTHER institution too, purely by sending a bad update — the aggregation-layer equivalent of Module 1's data poisoning, but harder to catch because the server never sees the underlying cause.

⬇ Run this lesson in the notebook

No new formula — this attack exploits Concept 2's aggregation rule exactly as written: a coordinate-wise MEAN gives every client's returned weights EQUAL, unweighted trust, so one arbitrarily extreme update pulls the average arbitrarily far. Concept 6 replaces that assumption.

CONCEPT 6

Byzantine-Robust Aggregation

Fixing the aggregation rule itself, without ever inspecting any client's data.

Overview

🧮 Math & Algorithm

What it is

Two classic robust aggregation rules replace the simple mean: coordinate-wise median (the middle value per parameter across all clients) and trimmed mean (discard the most extreme values per parameter before averaging the rest). Both limit how much a single outlier update can influence the aggregated result.

Why it exists — the history

2018

Yin et al., "Byzantine-Robust Distributed Learning," and related work formally analysed coordinate-wise median and trimmed mean as aggregation rules that remain robust as long as malicious participants stay a MINORITY — long-standing ideas from robust statistics, applied specifically to the federated/distributed learning setting.

✓ What the notebook demonstrates

Both rules substantially recover the accuracy Concept 5's attack destroyed, using ONLY the returned weights — no institution's raw data or training process is ever inspected

✗ An honest limitation, stated plainly

Neither rule defends against a COLLUDING MAJORITY of malicious institutions — median and trimmed mean both assume malicious participants are outnumbered, a real constraint worth naming rather than implying these defences are unconditional

REAL-WORLD FINANCIAL EXAMPLE

The notebook's median-defended global model performs essentially as well as the fully honest baseline, DESPITE the same corrupted update from Concept 5 still being submitted every round — the server never had to identify which institution was compromised, only change how it combined the results.

⬇ Run this lesson in the notebook

Coordinate-wise median: w[j] = median(w₁[j], w₂[j], ..., w_K[j])

Trimmed mean: w[j] = mean of the middle (K − 2·trim) values of (w₁[j], ..., w_K[j])

Both formulas apply PER PARAMETER j independently, across all K clients' returned weights for that parameter.

Median: a single extreme outlier value can only shift the MIDDLE value by a bounded amount, unlike a mean, which any one sufficiently extreme value can pull arbitrarily far.

Trimmed mean with trim = number of malicious clients removes exactly that many of the highest and lowest values per parameter before averaging what remains — correct if the true number of malicious clients is known or safely over-estimated.

CONCEPT 7

Fairness Under Federation

Module 6's audit was tied to a centralized model. Does it still hold?

Overview

🧮 Math & Algorithm

What it is

Module 6 measured demographic-parity and equalized-odds gaps by age group on a CENTRALLY trained classifier. This lesson re-runs the EXACT same audit on the federated model from Concept 2, to check whether federation itself changes that fairness profile.

Why it exists — the history

A direct extension of Module 6's own governance framework

Module 6 insisted that excluding a protected attribute from a model's features does not, by itself, guarantee fairness — it has to be measured. This lesson applies that same discipline one level up: training a model differently (federated vs. centralized) is itself a change that fairness has to be RE-measured against, not assumed to carry over.

✓ What the notebook demonstrates

A real, measured comparison: the federated model's demographic-parity and equalized-odds gaps genuinely differ from the centralized model's — moving in different directions on the two metrics, not uniformly better or worse

✗ What NOT to conclude

This is a single comparison on one dataset and one architecture — it is NOT evidence that federation always helps or always hurts fairness; the finding is that it CHANGES, which is itself the reason to re-audit rather than assume

REAL-WORLD FINANCIAL EXAMPLE

If RR Finance switched from a centralized to a federated training pipeline for any regulatory or commercial reason, Module 6's fairness sign-off would need to be re-obtained on the NEW model — this lesson is the concrete demonstration of why.

⬇ Run this lesson in the notebook

Identical formulas to Module 6 — demographic parity difference and equalized odds difference, computed on the same age bins and the same test set. See Module 6's handbook page for the full formulas; nothing here changes them. What changes is only WHICH trained model they are applied to.

Module 7 hand-off

The notebook implements a real FedAvg loop across 5 simulated institutions, measures the real accuracy cost of realistic non-IID data, trains the same architecture under real DP-SGD (via opacus) across five different privacy budgets, demonstrates a real model-poisoning attack against naive aggregation, defends against it with two real Byzantine-robust aggregation rules, and re-runs Module 6's fairness audit on the federated model to show it must be re-measured, not assumed -- with a metrics summary saved as an artifact for the next module.

What Module 8 builds on this

Module 8 (Multimodal AI) shifts RR Finance to a new kind of input entirely -- speech, document images, and vision-language understanding, building on Module 2's CNN foundations. It doesn't directly extend Module 7's federated/DP machinery, but the discipline this module established -- measure the real trade-off, don't assume a technique is free, re-audit governance under any new training regime -- carries forward to every module after it.

←Back to all 12 modules ←Back to Module 6