FL Explainer

Credit scoring

Vertical Federated Learning for Credit Scoring Models Without Label Leakage

Industry

Banking sector, financial services, scoring products

Technology

Vertical Federated Learning (VFL)

Data type

Tabular (structured) data

ML models

Gradient Boosting (GBDT)

ML task

Credit scoring

Product

Guardora VFL

Customer profile

The customer is a vendor company in the field of analytical products and predictive analytics that provides credit-scoring services to commercial banks.

The vendor holds an extensive body of data about users and, on this basis, builds creditworthiness assessment models for financial institutions.

The vendor’s clients use these models to make credit decisions, manage risk, and counter fraud.

Customer characteristics:
  • High requirements for compliance with personal-data protection legislation

  • Need to enrich models with external data sources without compromising confidentiality

  • Use of predictive analytics for credit scoring and risk assessment

Problem statement

The analytics-product vendor provides credit-scoring services to commercial banks. In the current process, the joint model is built using an ensembling method (stacking): each party trains its own model on its own data, after which the outputs of both models are combined into a final score.

To train the model on the vendor’s side, the labels (the target variable) must be transferred from the bank in the clear. The labels are confidential bank information containing the historical creditworthiness data of its clients. Transferring the labels requires agreement between the parties and compliance with internal information-security and compliance procedures.

The vendor’s core question: can different companies build a single ML model without disclosing data to each other, so that the final model uses the datasets of all parties, and the model quality is better than the quality of the individual local models?

Three key challenges:

  • Label confidentiality: the bank is not willing to transfer the target variable to an external partner.
  • Data decentralisation: features are distributed between the two parties.
  • Regulatory constraints: data transfer is restricted by law.

Testing objective: to compare the quality of a model trained using Vertical Federated Learning (VFL) with the quality of each party’s local model, and with the quality of the two-model ensemble (stacking), on the condition that within VFL, the labels are not transferred between parties.

Solution

To solve this problem, the Guardora VFL platform was deployed

A vertical federated learning solution in which two parties jointly train an ML model without transferring raw data or labels.

Participants and data distribution

The test was conducted simulating two parties:

01/

Active party (bank): holds the labels (the target variable, a binary creditworthiness indicator 0/1), the client identifiers, and some of the features.

02/

Passive party (vendor): holds ~200 features for the same clients, but has no labels.

Models and data protection

The testing was performed using a Gradient Boosting on Decision Trees (GBDT) model (a model consisting of 100 trees with a maximum depth of 6), the primary model for working with tabular data.

Data protection is provided under two security modes:

  • Homomorphic encryption of gradients (Paillier algorithm), the maximum level of protection: raw data and gradients never leave the perimeter in the clear.
  • No-encryption mode, raw data is not transferred, but gradients are transmitted in the clear. Provides high training speed.

Results

Comparison of approaches

The table below presents the test results:

ApproachROC_AUCLabel transfer
Local model of party A67.6Not required
Local model of party B70.1Required
Ensemble of two models (stacking)71.3Required
Guardora VFL (GBDT)≈ 81.3Not required

For the computation of party B’s local model within the test scenario, the labels were used.

Key result: following hyperparameter optimization, the VFL model achieved performance exceeding that of a two-model ensemble (stacking) and significantly outperforming each party’s local models. No label sharing occurred between participants.

Thus, in the modelled scenario, the vendor’s clients (banks) obtain a model that surpasses ensemble-level performance without label sharing.

The training and inference speed of the federated model is comparable to the training and inference speed of a standard scoring model:

  • Training the GBDT model without encryption on 300,000 records takes less than 9 minutes.
  • Training the gradient-boosting model with encryption on 50,000 records takes approximately 1.4 hours.
  • Inference speed is optimised: 650 requests per second in a multi-threaded implementation (0.008 s per request).

Detailed experimental results

The table below shows the ROC_AUC results of the federatively trained model for different numbers of data rows (samples) and the applied training method, gradient boosting.

NoSampleEncryptionROC AUCTime
110K-76.7236.5 s
250K-79.151.5 m
3100K-79.062.9 m
4200K-79.775.9 m
5300K-78.828.9 m
610K+76.3238 m
750K+78.781.4 h
8400K+81.3013h

*The results were achieved through experiments involving changes to the model hyperparameters

Key conclusions

In the described credit-scoring use case on tabular data with GBDT (100 trees, max depth 6), Guardora VFL achieved ROC AUC ≈ 81.3, outperforming a stacking ensemble of two separately trained models (71.3), the bank's local model (70.1) and the vendor's local model (67.6). Also the stacking ensemble requires label transfer between parties, while Guardora VFL does not.

Federated learning uses the data of both parties to build a unified model without violating confidentiality requirements.

The training speed without encryption is considered high, and with encryption, acceptable for industrial use.

The solution has undergone full-scale testing within the perimeter of a major technology company on real-world data.

FAQ

What is vertical federated learning for credit scoring?
Vertical Federated Learning (VFL) for credit scoring is a configuration where two organizations — typically a bank and an analytics-product vendor — jointly train a creditworthiness ML model without sharing the underlying customer data or labels. The bank (active party) holds creditworthiness labels and client identifiers plus some features. The vendor (passive party) holds a different feature set for the same clients (~200 features in this case). VFL uses cryptographic protocols and synchronized gradient computation so that each party contributes its features to the joint model — but neither party ever sees the other's raw data, and the bank's labels never leave its perimeter. Result: a unified model trained on the combined feature space without any data leakage.
How does VFL solve the label-sharing problem in credit scoring?
In a traditional stacking ensemble (the current production approach), the analytics vendor trains its own local model on its features — but the bank must transfer the creditworthiness labels to the vendor so the vendor can train. Labels are highly confidential bank information containing historical client creditworthiness data, and label transfer requires legal agreements, compliance reviews, and ongoing audit. VFL eliminates this entirely: gradient computation happens via secure synchronization between active (bank, has labels) and passive (vendor, has features) parties. The bank's labels stay inside the bank's perimeter; only encrypted gradients flow between parties. No legal label-transfer arrangement is required.
What's the ROC-AUC benchmark — VFL vs stacking vs local models?
Concrete results from this case study, using GBDT (100 trees, max depth 6) on tabular data.
Local model of party A (bank features only): ROC-AUC 67.6 (no label transfer needed — bank can train locally).
Local model of party B (vendor features only): ROC-AUC 70.1 (requires label transfer from bank).
Stacking ensemble of A + B: ROC-AUC 71.3 (requires label transfer for B).
Guardora VFL (GBDT on combined feature space): ROC-AUC ≈81.3 (no label transfer). VFL outperforms the production stacking method by 10 percentage points AND removes the operational/legal burden of label sharing. This is the single strongest commercial argument for VFL over stacking.
How does VFL credit scoring training speed compare to standard models?
Training and inference speeds are production-grade.
Without encryption: GBDT model trains on 300,000 records in under 9 minutes.
With Paillier homomorphic encryption (maximum security): 50,000 records in ~1.4 hours.
Inference: optimized for production — 650 requests per second in multi-threaded implementation, equivalent to 0.008 seconds per request. The detailed experiment table shows scaling: 10K samples no-encryption = 36.5 seconds; 50K = 1.5 minutes; 200K = 5.9 minutes; 400K with encryption = 13 hours. For real-time credit decisions, inference latency is the binding constraint and 8ms is well within acceptable bounds.
How does homomorphic encryption affect VFL training time?
Paillier homomorphic encryption adds significant compute overhead but is acceptable for production. Comparison (50K samples GBDT): without encryption = ~1.5 minutes; with Paillier encryption = ~1.4 hours. That's roughly 56× slower with encryption — the cost of mathematical privacy guarantees. Mitigation strategy: the case study uses two security modes selectable per training run.
1. Paillier homomorphic encryption: maximum protection, raw data and gradients never leave perimeter in cleartext — used for initial production training rounds and compliance-critical updates.
2. No-encryption mode: raw data still never transferred, but gradients are transmitted in cleartext — used for rapid iteration, hyperparameter tuning, and high-frequency retraining where the trust model permits.
Why is VFL better than ensemble stacking for credit scoring?
Two reasons combine.
1. Quality: VFL achieves ROC-AUC 81.3 versus stacking's 71.3 — a 10-point improvement. This happens because VFL trains a single unified model on the combined feature space (so the model can learn cross-party feature interactions), while stacking trains two separate models whose outputs are blended at the end (losing the inter-party feature interactions).
2. Operational simplicity: stacking requires label transfer from bank to vendor — which means legal agreements, audit obligations, compliance reviews, and recurring re-authorization. VFL eliminates this entirely. The vendor never sees the labels. For a regulated bank, the operational simplicity may be more important than the accuracy gain.
Who are the typical active and passive parties in VFL credit scoring?
Active party (bank): holds the labels (the target variable — binary creditworthiness 0/1), the client identifiers, and some features. Provides the supervision signal for training. In production deployments, the active party is typically a major commercial bank with deep historical credit performance data.
Passive party (vendor): holds rich features for the same clients but no labels — in this case study, ~200 features. Provides feature breadth. In production deployments, passive parties are typically analytics vendors, credit bureaus, telecom data providers, e-commerce platforms, or any organization with rich behavioral signals on potential borrowers but no direct credit performance history. VFL can in principle be extended to N-party configurations beyond two parties.
How does this case relate to Guardora's other FL primitives (HFL, FHE)?
Guardora's three production-deployed PPML primitives now have publicly-documented case studies.
Vertical FL (this case): ideal when two parties have different features for the same clients — bank + vendor credit scoring.
Horizontal FL (Pack 18 Fraud Detection): ideal when parties have the same features for different clients/transactions — bank + payment system fraud detection.
Fully Homomorphic Encryption (Pack 17 Oil & Gas): ideal when multiple parties pool similar data and end-to-end encryption is required — oil and gas joint model training across enterprises. Selecting the right primitive is the first step in any Guardora engagement — contact us for a scoping session to determine the optimal configuration for your case.