Vertical Federated Learning is a decentralized machine learning paradigm where two or more parties, each holding different feature sets for a shared set of data samples (e.g., overlapping users), collaboratively train a model without directly exchanging their raw, private data. This contrasts with horizontal federated learning, where parties share the same feature space but different samples. The core technical challenge is secure data alignment—identifying overlapping entities without exposing non-intersecting records—often solved using cryptographic protocols like Private Set Intersection (PSI).
Glossary
Vertical Federated Learning
Vertical Federated Learning (VFL) is a decentralized machine learning scenario where multiple organizations, each holding different feature sets for the same or overlapping set of users, collaboratively train a model without exchanging raw data.
FEDERATED CONTINUAL LEARNING
What is Vertical Federated Learning?
A decentralized machine learning scenario where multiple parties collaborate to train a model using different features from the same set of entities.
Following alignment, training proceeds with features partitioned vertically across participants. Common architectures use entity-aligned split neural networks, where different layers or components of the model are computed by different parties. Techniques like homomorphic encryption or secure multi-party computation protect intermediate outputs (e.g., gradients or embeddings) exchanged during training. This approach is prevalent in cross-industry collaborations, such as between a bank and an e-commerce platform building a joint credit model using financial and behavioral features.
DEFINING FEATURES
Key Characteristics of Vertical Federated Learning
Vertical Federated Learning (VFL) is a privacy-preserving collaborative learning scenario where different parties hold different feature sets for the same or overlapping set of data samples (e.g., users). Unlike horizontal FL, which partitions data by samples, VFL partitions by features, requiring specialized protocols for secure alignment and joint model training.
01
Feature Partitioning Over Same Samples
The core characteristic of VFL is that collaborating entities hold different features for the same or overlapping set of data entities (e.g., customers, patients). For example:
- A bank holds a user's financial transaction history.
- An e-commerce platform holds the same user's purchase history and browsing data.
- A hospital holds the same patient's medical records.
The goal is to train a model that utilizes this combined feature space without any party exposing its raw data. This requires first securely identifying the overlapping user set, typically via a protocol like Private Set Intersection (PSI).
02
Secure Sample Alignment (PSI)
Before training can begin, parties must identify their common users without revealing non-overlapping users. This is achieved through cryptographic protocols.
- Private Set Intersection (PSI): The primary technique. It allows two or more parties to compute the intersection of their private ID sets, learning only which IDs are shared and nothing about the other party's non-matching IDs.
- PSI-CA (Cardinality): A variant where parties learn only the count of overlapping users, not their identities.
- Alignment is a prerequisite: All subsequent model training steps operate only on this aligned, intersected dataset. Failure to align securely leaks membership information.
03
Split Neural Network Architecture
The model architecture in VFL is inherently split across parties.
- Bottom Models: Each party holds a local model component (the bottom layers) that processes its private features. These outputs are encrypted embeddings or intermediate results.
- Top Model: A combined model (often held by a coordinator server or one of the parties) that takes the concatenated outputs from all bottom models to produce the final prediction (e.g., credit risk, ad click probability).
- Forward Pass: Features → Local Bottom Model → Secure transmission of intermediate results → Top Model → Final output.
- Backward Pass: Gradients are passed back from the top model to each bottom model to update local parameters, often using homomorphic encryption or secure multi-party computation (MPC) to protect gradient privacy.
04
Asymmetric Party Roles (Active/Passive)
Parties in VFL typically have asymmetric roles, defined by who holds the labels needed for supervised learning.
- Active Party (Label Holder): The party that possesses the target labels (e.g., loan default flag, purchase label). This party usually hosts the top model and coordinates the training process.
- Passive Party (Feature Holder): Parties that contribute only features, without labels. They host only their bottom model.
- Coordinator Server: In some architectures, a neutral third server acts as the top model holder and coordinator to ensure no single party has undue advantage. The protocol must prevent the active party or coordinator from inferring passive parties' raw feature data from the exchanged intermediates or gradients.
05
Privacy-Preserving Forward & Backward Pass
Every step of the training loop requires privacy protection to prevent data leakage from intermediate computations.
- Forward Pass Protection: The outputs from bottom models (embeddings) must be masked or encrypted before being sent to the top model to prevent reconstruction of raw features.
- Backward Pass Protection: Gradients passed from the top model to bottom models can reveal information about the top model's weights and other parties' data. Techniques include:
- Homomorphic Encryption (HE): Allows computation on encrypted data.
- Secure Multi-Party Computation (MPC): Splits computations so no single party sees the whole.
- Differential Privacy (DP): Adding calibrated noise to gradients or outputs.
- The combination of cryptographic techniques and model splitting creates a 'privacy barrier’.
06
Primary Use Cases & Industry Fit
VFL is uniquely suited for cross-industry, cross-organization collaboration where entities share a common customer base but possess complementary data dimensions.
- Finance & Marketing: A bank (credit history) collaborates with an e-commerce platform (purchase behavior) for a joint credit scoring or recommendation model.
- Healthcare: Multiple hospitals with different diagnostic tests (genomic, imaging, clinical) for the same patients collaborate on a disease prediction model.
- Smart Cities: A transportation agency (travel data) works with a telecom provider (location pings) to optimize traffic flows.
- Key Driver: Compliance with data protection regulations (GDPR, HIPAA) that prevent raw data centralization or sharing. VFL enables data cooperation without data consolidation.
ARCHITECTURAL COMPARISON
Horizontal vs. Vertical Federated Learning
A structural comparison of the two primary data partitioning scenarios in decentralized learning, highlighting their distinct mechanisms, applications, and system requirements.
| Feature | Horizontal Federated Learning (HFL) | Vertical Federated Learning (VFL) |
|---|---|---|
Core Data Partition | Same feature space, different sample IDs (users). | Same sample IDs (users), different feature spaces. |
Primary Use Case | Cross-device learning (e.g., next-word prediction on millions of phones). | Cross-silo learning (e.g., a bank and an e-commerce company enriching a joint user risk model). |
Sample Alignment Requirement | Not required; clients have disjoint user sets. | Required; a secure protocol like Private Set Intersection (PSI) is needed to find overlapping users. |
Model Architecture | Clients train identical model architectures on local data. | Parties train different sub-models on their local features; a fusion component (e.g., fully connected layer) combines outputs. |
Privacy Leakage Focus | Protecting local training data (sample-level privacy). | Protecting local feature vectors and label information (feature-level privacy). |
Communication Overhead | High-frequency, lightweight updates (e.g., gradients) from many clients. | Lower-frequency, potentially heavier communication for aligned sample coordination and forward/backward passes. |
Typical Scale | Massive (10^3 to 10^6 clients). | Small (2 to 10 organizations). |
Cryptographic Primitives | Secure Aggregation, Differential Privacy. | Private Set Intersection, Homomorphic Encryption, Secure Multi-Party Computation. |
System Heterogeneity Tolerance | Must handle vast device variability and partial participation. | Assumes reliable, resource-rich organizational servers. |
APPLICATIONS
Common Use Cases for Vertical Federated Learning
Vertical Federated Learning (VFL) enables collaborative model training across organizations that hold different data features about the same entities. This unlocks insights without sharing raw data. Below are its primary industrial applications.
VERTICAL FEDERATED LEARNING
Frequently Asked Questions
Vertical Federated Learning (VFL) enables collaborative model training across organizations that hold different features for the same or overlapping user populations. This FAQ addresses its core mechanisms, security protocols, and practical applications.
Vertical Federated Learning is a decentralized machine learning paradigm where multiple parties, each holding different feature sets for the same or overlapping set of data samples (e.g., users), collaboratively train a model without directly sharing their raw data. It works by first securely aligning the overlapping samples—often using a protocol like Private Set Intersection (PSI)—and then training a model where each party computes on its local features. A common architecture involves a bottom model on each client for local feature extraction and a top model (often hosted by a coordinator) that aggregates these intermediate outputs for final prediction, with gradients passed back securely.
Key Steps:
- Secure Sample Alignment: Parties use PSI to privately identify common users/entities without revealing non-intersecting data.
- Encrypted Entity Alignment: For overlapping but not identical user sets, techniques like encrypted IDs are used.
- Split Learning: The model is partitioned vertically. Each party trains its segment on local features.
- Secure Forward/Backward Pass: Intermediate outputs (embeddings, gradients) are exchanged using encryption (e.g., Homomorphic Encryption) or secret sharing to prevent data leakage.
- Aggregation & Update: A coordinator securely aggregates contributions to update the parts of the model it holds.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.
Enterprise searchRAGPermissions
Read more
Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.
AI agentsWorkflow automationGovernance
Read more
Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
AI integrationDecision supportModel routing
Read more
About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
LinkedIn
Limited slotsGet a Free AI Consultation
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us