Vertical model fairness is the assessment and mitigation of discriminatory biases in machine learning models trained via Vertical Federated Learning (VFL), where the unequal distribution of predictive features across different data-owning parties can introduce or amplify unfair outcomes. Unlike centralized training, fairness risks in VFL stem from structural asymmetry—where one party holds labels and others hold features—and feature heterogeneity, where the quality and relevance of features vary significantly between participants, potentially disadvantaging entities described by less predictive data sources.
Glossary
Vertical Model Fairness

What is Vertical Model Fairness?
A specialized domain of algorithmic fairness focused on biases that emerge from the structural and data distribution characteristics unique to Vertical Federated Learning (VFL).
Achieving fairness in VFL requires specialized techniques that operate within the paradigm's privacy constraints. This involves federated fairness metrics computed without centralizing data, bias auditing on aligned intermediate representations, and mitigation strategies like constrained optimization or re-weighting applied during the secure, distributed training protocol. The goal is to ensure the final collaborative model does not produce disparities correlated with the originating data party or the specific feature subsets available for different population groups.
Key Challenges in Vertical Model Fairness
Ensuring fairness in models trained via Vertical Federated Learning (VFL) introduces unique complexities beyond centralized training, stemming from data distribution, coordination, and privacy constraints.
Feature Distribution Bias
In VFL, predictive features are vertically partitioned across different parties. This can lead to feature distribution bias, where one party holds features that are more predictive for certain demographic groups than others. For example, a bank may hold income data (strongly predictive) while a retailer holds purchase history (weakly predictive) for the same customers. The model may become unfairly reliant on the bank's features, disadvantaging groups underrepresented in that dataset. Mitigation requires analyzing feature importance per subgroup across parties.
Label Owner Bias Amplification
The label owner (e.g., a financial institution with loan outcomes) controls the target variable and typically orchestrates training. This central role can inadvertently amplify existing societal biases present in their labels. In a split neural network, the label owner's model segment makes the final prediction, giving it disproportionate influence. If the label data is historically biased (e.g., past discriminatory lending), the VFL protocol can propagate and even obscure this bias within the intermediate outputs received from feature owners. Auditing requires algorithmic explainability techniques applied to the distributed model.
Fairness-Aware Secure Aggregation
Standard vertical secure aggregation protocols cryptographically combine updates from feature owners to preserve privacy. However, these protocols are typically fairness-agnostic; they aggregate contributions (e.g., gradients) equally, which can perpetuate bias if some contributions are less fair. Designing fairness-aware aggregation requires modifying protocols to weight updates based on fairness metrics, which must be computed without breaking privacy. This intersects with secure multi-party computation (MPC) to compute fairness statistics like demographic parity or equalized odds on the encrypted, aligned dataset.
Disparate Impact of Privacy Mechanisms
Privacy-preserving techniques essential to VFL, such as differential privacy (DP) and homomorphic encryption, can have a disparate impact on model fairness. Adding DP noise to gradients or intermediate outputs often degrades accuracy more for underrepresented subgroups, exacerbating performance disparities. The privacy-utility-fairness trade-off becomes a three-way optimization problem. For instance, a (ε=1.0, δ=10^-5) DP guarantee might reduce overall accuracy by 2% but reduce recall for a minority group by 15%. Mitigation involves developing subgroup-specific privacy budgets or adaptive noise addition.
Partial & Asymmetric Information
No single party in VFL has a complete view of all features for all entities, creating partial information asymmetry. This makes comprehensive fairness auditing nearly impossible for any participant. A feature owner cannot compute fairness metrics because they lack labels; the label owner cannot because they lack the full feature set. This necessitates collaborative fairness auditing protocols where parties jointly compute metrics like disparate impact ratios without revealing sensitive data. Techniques from federated model evaluation and private set intersection must be extended to measure bias across the aligned entity set.
Entity Alignment Skew
The initial entity alignment step, often using Private Set Intersection (PSI), determines which overlapping records parties will train on. If the intersection is not representative of the broader population—for example, if it over-represents urban customers shared between a bank and a telecom—the resulting model will inherit this sample selection bias. This skew is compounded if alignment is performed only once at the start of a long-running VFL process. Dynamic re-alignment or fairness-aware PSI that aims for a demographically representative intersection are emerging research areas to address this foundational challenge.
How is Vertical Model Fairness Achieved?
Achieving model fairness in Vertical Federated Learning (VFL) requires specialized techniques to detect and mitigate bias that originates from the distributed, non-IID nature of vertically partitioned features across multiple data owners.
Vertical model fairness is achieved by implementing bias auditing and mitigation protocols throughout the VFL lifecycle. This begins with pre-training disparity assessment, where parties use secure computation to evaluate feature distributions and correlations with sensitive attributes across the aligned entity set. Techniques like federated reweighting or adversarial debiasing are then applied during the vertical training protocol, often by incorporating fairness constraints into the split neural network's loss function or gradient updates.
Post-training, fairness-aware evaluation is conducted using the vertical inference protocol to measure performance disparities across protected groups without reconstructing raw data. Mitigation may involve federated feature selection to reduce dependence on proxy variables or applying differential privacy mechanisms that can sometimes help fairness by adding uniform uncertainty. Continuous monitoring is essential, as the label owner must coordinate these processes without direct access to the feature owners' sensitive data, relying on encrypted intermediates and aggregated statistics.
Critical Use Cases for Vertical Fairness
Vertical Federated Learning (VFL) introduces unique fairness challenges. These use cases highlight scenarios where bias can emerge from the distributed nature of features and the collaborative training process.
Credit Scoring & Loan Approval
In VFL, a bank (label owner with loan repayment history) collaborates with a telecom provider (feature owner with call/text patterns) and a utility company (feature owner with payment consistency). Bias risk arises if the telecom's features (e.g., frequent international calls) are only available for a specific demographic, leading the model to unfairly associate that pattern with creditworthiness. Mitigation requires auditing feature contributions per protected group.
Healthcare Diagnostics & Treatment
A hospital (label owner with diagnoses) trains a model with a genomics lab (feature owner with genetic markers) and a wearable device company (feature owner with activity data). Vertical fairness is critical because the genomic data, often held by one party, may be disproportionately available for certain ethnic groups. If the model learns to rely heavily on these features, it could underperform for populations where such data is scarce, leading to diagnostic disparities.
Personalized Advertising & Recommendation
An e-commerce platform (label owner with purchase history) partners with a social media company (feature owner with engagement data) and a financial data aggregator (feature owner with spending categories). Unfair targeting can occur if high-value spending features from the aggregator correlate with income or zip code, potentially leading the model to systematically exclude lower-income groups from seeing premium product ads. Fairness audits must track how combined features from different parties create proxy variables for protected attributes.
Fraud Detection in Financial Networks
A payment processor (label owner with fraud tags) collaborates with multiple merchant banks (feature owners with transaction contexts). Bias amplification is a key concern. If one merchant bank primarily serves small businesses in a specific region, its local transaction patterns (features) might be incorrectly associated with higher fraud risk by the global model. This can lead to unfair transaction denials for legitimate customers from that demographic or business sector.
Talent Acquisition & HR Analytics
A corporation's HR department (label owner with promotion/retention data) uses VFL with a professional networking platform (feature owner with skill endorsements) and an internal IT system (feature owner with software usage logs). Fairness violations can emerge if the networking platform's endorsement features are more prevalent for employees from certain universities or companies, creating a feedback loop that advantages those groups in promotion predictions. Isolating the bias contribution of each party's feature set is essential.
Cross-Device User Profiling
A service provider aims to build a unified user profile by combining data from a smartphone OS (feature owner with app usage), a smart home system (feature owner with device interactions), and a streaming service (label owner with content preferences). Privacy-preserving fairness is challenged because sensitive inferences about household composition or disability could be made from the smart home features. If these inferred attributes correlate with the label, the model may make unfair recommendations without any party holding explicit demographic data.
Frequently Asked Questions
Vertical model fairness addresses the unique challenges of bias assessment and mitigation in models trained via Vertical Federated Learning (VFL), where predictive features are distributed across different organizations.
Vertical model fairness is the systematic assessment and mitigation of discriminatory biases in machine learning models trained via Vertical Federated Learning (VFL), where the unequal distribution of sensitive or predictive features across participating parties can introduce or obscure bias. Unlike centralized training, VFL's data partitioning means no single entity has a complete view of all features for all samples, complicating traditional fairness audits that require access to the full feature set and protected attributes (e.g., race, gender). This paradigm necessitates new methodologies to evaluate metrics like demographic parity or equalized odds without centralizing data, ensuring the collaboratively trained model does not produce disproportionately adverse outcomes for any legally protected or socially salient group.
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.

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.

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.
Related Terms
Vertical Model Fairness is intrinsically linked to the technical architecture and privacy mechanisms of Vertical Federated Learning. Understanding these foundational concepts is crucial for assessing and mitigating bias in this distributed paradigm.
Vertical Federated Learning (VFL)
Vertical Federated Learning (VFL) is a decentralized machine learning paradigm where different parties (clients) hold different features about the same set of entities (e.g., customers), and collaborate to train a model without directly sharing their raw feature data. This is distinct from horizontal FL, where parties have different samples of the same features.
- Core Mechanism: Entities are aligned across parties, and a model (often a split neural network) is trained collaboratively.
- Primary Use Case: Common in finance (bank + insurer) and healthcare (hospital + lab) where data about the same patient exists in separate feature silos.
- Fairness Implication: The distribution of predictive features across parties can be inherently unequal, creating a primary source of bias that must be measured and corrected.
Split Neural Network
A split neural network is the standard model architecture used in VFL, where the network is divided into multiple parts, each residing on a different party. The division point is called the cut layer.
- Feature Owner's Sub-Model: The portion of the network from the input layer up to the cut layer. It processes local features and produces an intermediate output.
- Label Owner's Sub-Model: The portion from the cut layer to the output layer. It receives intermediate outputs from feature owners to complete the forward pass and compute the loss.
- Fairness Implication: Bias can be encoded in the intermediate representations generated by any party's sub-model. Auditing fairness requires examining gradients and activations across this split architecture.
Private Set Intersection (PSI)
Private Set Intersection (PSI) is a cryptographic protocol that allows two or more parties to compute the intersection of their private datasets (e.g., sets of user IDs) without revealing any information about items not in the intersection. It is a prerequisite for entity alignment in VFL.
- Role in VFL: Before training begins, parties use PSI to securely identify the common set of entities they all have data for, without exposing their full customer lists.
- Fairness Implication: The resulting aligned dataset may not be representative of any single party's full population. This selection bias must be accounted for in fairness assessments, as the collaborative model is only trained on the intersected subset.
Vertical Secure Aggregation
Vertical secure aggregation refers to cryptographic protocols used in VFL to combine model updates (e.g., gradients or intermediate outputs) from multiple feature owners without revealing any individual party's contribution. This protects data privacy during training.
- Common Techniques: Utilizes Secure Multi-Party Computation (MPC) or Homomorphic Encryption to perform computations on encrypted data.
- Fairness Implication: While essential for privacy, secure aggregation can obscure the origin of model updates, making it challenging to attribute specific biased behaviors to a particular party's data. Fairness auditing must be designed to work within these cryptographic constraints.
Vertical Federated Averaging (VFA)
Vertical Federated Averaging (VFA) is a class of collaborative learning algorithms designed for the vertical data partition setting. Unlike horizontal FedAvg, VFA coordinates the training of a split model by aggregating updates from feature owners to form a global model.
- Process: The label owner typically coordinates the process, sending gradients back to feature owners, who then update their local sub-models.
- Fairness Implication: The aggregation mechanism and the frequency of updates from each feature owner can influence fairness. If one party's data is updated more frequently or with higher magnitude, the model may become biased toward the patterns in that data source.
Vertical Inference Protocol
A vertical inference protocol defines the secure, collaborative process for making predictions using a vertically split model after training. Feature owners provide local feature inputs without revealing them to generate a final prediction.
- Mechanism: During inference, each feature owner computes the forward pass on its local sub-model and sends the intermediate result to the label owner (or a coordinator), who completes the computation.
- Fairness Implication: This is the point where potential bias manifests in real-world decisions (e.g., loan denial, medical diagnosis). Monitoring for disparate impact across demographic groups must be integrated into the inference pipeline, despite the distributed and private nature of the feature inputs.

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.
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