Federated Learning
What Is Federated Learning?
Federated learning trains one shared machine learning model across separate devices or organizations without moving raw data to a central location. The model goes to the data, participants improve it locally, and a coordinator combines updates into a global model.
A participant, or client, may be a phone, hospital, bank, factory machine, or company server. Federated learning enables distributed collaboration while participants retain control of source data. It does not guarantee privacy, security, fairness, or legal compliance. Updates can reveal information, so technical and governance controls are needed.
For a broader introduction, see machine learning. Federated learning is useful when data is sensitive, difficult to move, separately governed, or created continuously at the network edge.
How Federated Learning Works
Training occurs in repeated rounds. Clients may miss rounds because they are offline, busy, or low on battery.
- A coordinator defines the task, model, participation rules, and success measures.
- The system selects eligible clients, such as available phones or approved servers.
- The coordinator sends a starting global model to selected clients.
- Each client trains it on local data and calculates updates.
- Clients send updates, not raw records, through protected channels.
- The coordinator combines updates, often with Federated Averaging, which gives more weight to clients with more relevant examples.
- The global model is evaluated, redistributed, and refined until it meets agreed criteria.
For example, a keyboard model can learn from typing patterns on many phones without uploading typed messages to a central database.
The Key Components of a Federated Learning System
Clients hold local datasets and run training jobs. A coordinator, or aggregation server, schedules rounds and produces the global model. A network moves models and updates between them.
Other components include client selection, an aggregation algorithm, identity and access controls, and monitoring for failures or unusual updates. Clients may keep local models suited to their data, while the global model reflects the group.
Validation is essential. A model may perform well overall but poorly for a clinic, region, device type, or customer group. Teams should use a governed held-out evaluation dataset where possible, or federated evaluation that measures results without exposing records. Monitoring should track accuracy, fairness, participation, communication failures, and attacks.
Types of Federated Learning
Cross-device and cross-silo describe participants. Horizontal, vertical, and transfer learning describe how datasets relate.
| Type | What it means | Example |
|---|---|---|
| Cross-device | Many consumer or edge devices participate intermittently, usually with limited computing power. | Phones help improve next-word suggestions. |
| Cross-silo | A smaller number of stable organizations or servers collaborate under formal agreements. | Hospitals train a model to identify imaging patterns. |
| Horizontal | Participants have the same data fields, or shared feature space, but different people or events. | Retailers use transaction date, basket value, and product category for different customers. |
| Vertical | Participants have different data fields about some of the same people or entities. | A bank and insurer combine complementary information about shared customers. |
| Federated transfer learning | Participants have limited overlap in both data fields and people, so knowledge is adapted between settings. | Related regional providers adapt a model despite different records and populations. |
Federated Learning vs. Centralized Machine Learning
Federated learning complements rather than replaces centralized training. Centralized training is often simpler when data can be responsibly pooled and cleaned in one controlled environment.
| Factor | Federated learning | Centralized machine learning |
|---|---|---|
| Data location | Data stays with participating clients. | Data is moved to a central repository. |
| Governance | Requires agreements and controls across parties. | Usually managed by one organization and data environment. |
| Network and computing | Needs repeated communication and local compute. | Needs data-transfer pipelines and centralized compute. |
| Speed and quality control | Can be slower and harder to standardize across clients. | Usually easier to inspect, clean, and train on one dataset. |
| Best fit | Data cannot readily be pooled or must remain locally governed. | Data can be lawfully and safely centralized. |
Benefits of Federated Learning
Benefits depend on the data, participants, and safeguards. They are potential advantages, not guarantees.
- It reduces routine movement of raw data, lowering exposure during transfer and storage.
- Organizations can collaborate without sharing complete datasets.
- It can use data that is impractical, sensitive, or restricted from central pooling.
- It supports local personalization for a device or site.
- It may support data-residency or sovereignty requirements when local processing is appropriate.
- It avoids reliance on one central training dataset, although the coordinator remains an operational dependency.
Practical Limits and Security Risks
Keeping records local changes risk rather than removing it. Pilots should test operational and adversarial conditions before production use.
- Client data may differ sharply by hospital, device, or region, making the shared model less stable.
- Phones and edge devices can disconnect, lack battery power, or have limited bandwidth. Institutional clients can also miss rounds.
- Repeated rounds can make training slower and more expensive than centralized training.
- Poorly labeled or biased local data can degrade the global model and harm underrepresented groups.
- Updates can reveal training-data information unless protected by suitable privacy methods.
- Malicious clients can submit poisoned updates that reduce accuracy or create unsafe behavior.
- Auditing data quality, consent, security, and model behavior across participants is complex.
Where Federated Learning Is Used
Federated learning fits shared prediction tasks where direct data pooling is difficult. It is not needed for every AI project.
- Mobile keyboards, recommendations, and speech features can learn from on-device behavior while keeping raw interaction data on the device.
- Healthcare institutions can study diagnostic or treatment patterns across sites when patient records require local governance.
- Banks and payment providers can collaborate on financial crime detection when transaction histories are restricted or commercially sensitive.
- Industrial operators can improve predictive maintenance models from equipment data at separate plants or customer sites.
- Retail and telecommunications providers can model demand, service quality, or churn across distributed branches and networks.
Participants need compatible objectives, enough usable local data, and a reason not to centralize it. Building the surrounding product also requires sound app design and development, including user controls and reliable monitoring.
Privacy, Security, and Governance Safeguards
Local storage is insufficient because updates, metadata, and access patterns can create risk. Secure aggregation can prevent the coordinator from viewing an individual update, while encryption protects data in transit. Differential privacy adds calibrated noise to reduce the chance that a contribution is traced to an individual, though too much noise can reduce usefulness.
Organizations may use trusted execution environments, anomaly detection for suspicious updates, and robust aggregation that reduces outlier influence. Governance should define participation, permitted data, local retention, consent, and incident handling. Legal agreements and independent evaluation are especially important in cross-silo projects involving regulated or competing organizations.
When Federated Learning Is the Right Choice
Choose federated learning because it solves a real data-sharing constraint, not because it is more advanced than centralized training. A practical assessment should include these checks.
- Raw data cannot be centralized for legal, ethical, commercial, security, or operational reasons.
- Participants share a defined modeling goal and meaningful evaluation measures.
- Clients have sufficient compute, storage, connectivity, and support for the training schedule.
- Governance, consent, ownership, retention, and incident-response responsibilities are documented before training.
- The team can control update leakage and poisoning through safeguards and monitoring.
- A centralized, privacy-preserving, or synthetic-data alternative has been tested and is less suitable.
- The pilot includes diverse participants, realistic failures, and subgroup evaluation, not only average accuracy.
Common mistakes include assuming updates are harmless, selecting only well-connected participants, ignoring uneven data, and treating a successful prototype as proof of regulatory compliance. Start with the data and governance problem, then choose the simplest training architecture that meets it.
on Emergent today

