Federated Learning
Federated learning is a method of training a shared model across several parties — banks, hospitals, devices — without pooling their data: each party trains on its own records locally and sends only model updates to a coordinator, which combines them into a global model that is sent back; the records never leave their owner. In finance it is the candidate for cross-institution fraud and money-laundering models where sharing data is impossible; its limits are leakage and consortium governance.
- Also known as
- Federated machine learning, Collaborative learning, Privacy-preserving machine learning
- Used at
- on-device learning (keyboards, speech), healthcare (models across hospitals), and, in finance, cross-bank fraud and AML detection pilots, consortium credit models, and vendor models trained across clients without centralising their data; the production successes are on devices; the financial ones are mostly pilots and a few vendor products
- Binding
- data-protection law is the reason — a model trained without transferring personal data avoids the transfer's legal basis question, though updates can be personal data if they leak; competition law constrains what competitors may share; bank-secrecy rules in some jurisdictions forbid data sharing outright; the EU's Data Act and the AML package's information-sharing provisions are creating lawful channels
- Typical mechanics
- a coordinator distributes the model; each party trains a few steps on local data; parties return updates; the coordinator averages them (federated averaging) and repeats; secure aggregation (cryptographic combination so the coordinator sees only the sum), differential privacy (noise added to updates) and homomorphic encryption reduce what updates reveal; the parties' data can differ in distribution, which complicates training
- Typical limits
- updates can leak training data (model-inversion and membership-inference attacks), so privacy techniques are needed and cost accuracy; parties' data differ (a retail bank and a corporate bank), so one global model may fit none well; coordination requires trust in the coordinator and agreement on the model, the objective and the evaluation; and a consortium's members must each see a benefit
- Parties
- the institutions contributing data, the coordinator (a vendor, a consortium body or one member), the regulators who must be satisfied that no data moved, the privacy engineers, and the fraud and AML teams whose detection the model serves
How federated learning works in practice
Five banks want a model that detects money-mule accounts, which move funds between them; each sees only its own side, and none may share customer data. A coordinator distributes a model architecture; each bank trains it for an epoch on its own labelled accounts; each sends its weight updates through secure aggregation so that the coordinator sees only the combined update; the coordinator averages, updates the global model, and sends it back; twenty rounds later the global model has learned patterns visible only across the five, without any bank's records leaving it. Each bank runs the model on its own accounts. Detection of mule accounts rises at every bank, most at the smaller ones that had the least data of their own. The legal work — a consortium agreement, a data-protection assessment showing updates are not personal data after aggregation and noise, a regulator's comfort — took longer than the engineering.
The reason it is still mostly pilots in finance is in that last sentence. The technology works; the consortium is hard. Members must agree on the target, the features, the evaluation and the governance; the coordinator must be trusted or replaced by cryptography; the privacy techniques cost accuracy; and each member's benefit must exceed its cost, which is hardest for the largest member with the most data. The alternatives — a vendor that aggregates consortium data under contract, regulated information-sharing utilities, synthetic data — often win on simplicity. Where federated learning fits is where data cannot move at all and the parties are motivated: the AML case, the cross-border case, and the vendor case where a model improves across clients without their data pooling. For a fintech, it is a method to know and a consortium to join if one forms; for a buyer, a target's "federated" claim is diligenced on whether the consortium exists and what the updates reveal.
For a fintech, federated learning is the technical answer to a question — how to learn across institutions without sharing data — whose harder part is the agreement among them; for an investor, the vendors that have solved the agreement are the ones worth reading.
Example
A payments vendor serving 40 acquirers trains its fraud model federatedly: each acquirer's data stays in its environment; the vendor's coordinator aggregates secure updates with differential privacy; the global model detects fraud rings that hit several acquirers in sequence. Results: detection of cross-acquirer fraud rings rises from 38% to 71%; the privacy noise costs 1.5 points of AUC against a hypothetical pooled model; the smallest acquirers gain most. The consortium agreement took nine months and specifies the model, the evaluation, the exit terms and the vendor's obligations; the data-protection assessment, reviewed by two regulators, concluded the aggregated updates are not personal data. Three acquirers declined to join, citing competition concerns; the vendor's product is priced as a premium tier, and its acquirer two years later buys it for the consortium as much as the model.
Common mistakes
- Treating federated learning as a substitute for a legal basis; updates can leak, and the assessment must show they do not. - One global model across parties whose data differ, fitting none. - No secure aggregation, so the coordinator sees each party's update. - A consortium without agreed governance, evaluation and exit terms. - Reading a vendor's "federated" claim without asking who the other parties are.