Must the complete user populations be identical?

Not necessarily. Basic designs can operate on aligned overlap, while other settings require additional methods and assumptions.

Does vertical learning automatically make the data anonymous?

No. Local storage and distributed computation do not by themselves establish anonymity or a complete privacy guarantee.

Can a participant make predictions alone afterward?

It depends on the model and protocol. Some designs still require the other participant's feature contribution.

AI Glossary / Mathematics and optimization / Intermediate

Vertical federated learning

Definition

Vertical federated learning is collaborative model training in which participants hold different features about the same or overlapping entities. Instead of collecting all feature columns into one central dataset, participants coordinate computations across their locally held data. The vertical label refers to a feature-wise partition of an aligned dataset. The approach requires careful entity matching and a defined protocol for what information is exchanged.

What it means

Imagine two organizations observing different aspects of the same machines, products, or customers. One has one group of feature columns, another has a different group, and one participant may hold the target labels. Their complementary information can support a joint prediction task.
This differs from horizontal federated learning, where participants generally have the same feature structure for different observations. In vertical learning, matching the entities represented by each participant's rows is central.
The raw datasets can remain local, but information still moves through the protocol. Intermediate values, gradients, model outputs, identifiers, and repeated queries can matter for confidentiality. Federated organization alone is not a complete privacy guarantee.

How it works

Define the shared task, participating feature groups, label ownership, and permitted outputs. Establish how records referring to the same entity will be aligned, including how unmatched or ambiguous records are handled.
During training, participants calculate local contributions and exchange protocol-defined information so that the joint loss and parameter updates can be computed. Techniques such as secure multiparty computation or homomorphic encryption may be used, depending on the design and threat model.
Prediction can also require multiple participants to contribute, especially when the trained model depends on their separate features. The exact participation requirements, failure behavior, and information revealed must be specified. There is no single universal vertical-federated algorithm that determines these details for every application.

Three practical examples

Two equipment-service partners can explore a joint failure-prediction model using maintenance records and operating measurements for aligned assets.
Separate business units can train a model using complementary feature sets while retaining their local data systems and a controlled collaboration interface.
A research collaboration can study whether added feature groups improve predictions on common entities, comparing them with local-only baselines before accepting the added coordination cost.

Think of it this way

Think of two teams holding different columns of the same carefully indexed spreadsheet. They work together on a calculation without simply handing over their complete sheets. The analogy explains the partition, but it hides the hardest parts: agreeing which rows match, controlling what messages reveal, and making the computation reliable when a participant is unavailable.

Worked example

Consider an invented asset example. Participant A has machines M1, M2, and M3; participant B has M2, M3, and M4. Their straightforward aligned training subset contains M2 and M3, not four machines with complete combined features.
For M2, A holds features [2,3] with local weights [0.5,−1], giving contribution 0.5×2−3=−2. B holds feature 4 with weight 2, giving contribution 8. With an intercept of 1, the joint linear score is −2+8+1=7.
For M3, A holds [1,0], giving 0.5, and B holds 2, giving 4. The joint score is 0.5+4+1=5.5.
If the records are misaligned and M2 receives B's contribution for M3, its score becomes −2+4+1=3. M3 would incorrectly receive 0.5+8+1=9.5. All arithmetic remains executable, but it now describes nonexistent combined records.
This example illustrates feature partitioning and matching only. Sending these contributions in plain text is not presented as a privacy-preserving protocol, and no training procedure or security guarantee is demonstrated by the calculation.

Illustrative case study

In a fictional maintenance collaboration, a manufacturer and service provider propose using complementary machine records. A pilot discovers that one system uses replacement-unit identifiers while the other retains installation-site identifiers.
The partners resolve what constitutes an entity and create checks for replacements and ambiguous matches before evaluating a joint model. They compare predictions with each participant's local baseline and test what happens when one side cannot provide current features.
The lesson is that alignment and operational availability can be as important as model accuracy. The scenario does not claim a measured benefit or that any specific cryptographic design has been implemented.

Common misconceptions and mistakes

Do not describe vertical learning as simply averaging independent models trained on unrelated feature spaces. The participants contribute different information for aligned entities, so their coordination differs from standard horizontal aggregation.
Do not assume every participant must hold every label or every entity. Label ownership and overlap depend on the setup, but the chosen protocol must support them explicitly.
Do not treat encrypted transport as proof that all training messages are harmless. The confidentiality question includes what authorized recipients can infer from outputs and intermediate results.
Finally, a larger joint feature set can still produce a worse model through leakage, poor alignment, distribution differences, or unsuitable training choices.

Business use

Assess whether complementary features improve the intended task enough to justify matching, coordination, computation, and ongoing prediction dependencies. Measure the benefit against local models using an evaluation split that avoids future-information leakage.
Agree on responsibilities for feature freshness, entity mapping, model updates, participant outages, and access to outputs. Any privacy claim should identify the actual protocol and assumptions. This makes the collaboration reviewable as an operating system rather than an appealing promise that data never move.

Check your understanding

A holds columns temperature and pressure for machines A, B, and C. Another participant holds vibration for B, C, and D. Which machines have all three features in the straightforward overlap?

Answer: B and C. Machines A and D lack one participant's feature group and need separate handling.

Related terms

Federated learning
Horizontal federated learning
Local model
Inference
entity alignment
feature partitioning
secure multiparty computation
homomorphic encryption

Learn next

Draw a small two-participant table and identify overlapping entities before combining any feature contributions. Then document label ownership and the information exchanged in a proposed protocol. Study threat models and alignment errors before evaluating privacy or prediction claims.

Sources

Aalto Dictionary of Machine Learning, vertical federated learning entry. https://aaltodictionaryofml.github.io/ADictML_Main.pdf Yang and colleagues, Federated Machine Learning: Concept and Applications, sections 2.3.2 and 2.4.2: vertical partitioning, entity alignment, and protocol-specific computation. https://arxiv.org/pdf/1902.04885

Previous: Version space learning Next: Very large database