This page exists for the technical evaluator and the compliance reviewer who want to check our claims rather than take them on faith. It covers methodology and results plainly, including the parts that didn't work as well as we'd have liked.
Methodology
A 30-day remittance transaction prediction task across two UK fintech platforms, split into four client partitions by platform and geography. 21,458 users, 30 structured transaction features.
Centralised logistic regression trained on the pooled dataset, used as the performance ceiling against which federated approaches were measured.
Federated logistic regression trained with FedAvg across the four clients, with FedProx also tested to check robustness to heterogeneity between clients.
Differential privacy applied via per-sample gradient clipping and Gaussian noise, with Rényi DP accounting used to track the cumulative privacy budget across training rounds.
Secure aggregation simulated via Shamir secret sharing, tested to see whether it introduced any additional utility cost beyond differential privacy alone.
Results, reported honestly
Federated logistic regression trained with FedAvg reached 0.869 AUROC, against 0.864 AUROC for centralised logistic regression on the same problem. The federated model matched, and slightly exceeded, the centralised baseline. Within a fixed model class, moving from centralised to federated training did not cost predictive performance.
FedProx was tested to check robustness when clients have heterogeneous data distributions. At default settings, it provided negligible benefit over standard FedAvg. Under deliberately stressed heterogeneity conditions, it produced a small measurable gain. We report both results rather than only the favourable one.
Differential privacy, applied through per-sample gradient clipping and Gaussian noise with Rényi DP accounting, came with a real utility cost. At the privacy settings tested, model calibration degraded to the point of being degenerate, meaning predicted probabilities stopped reliably reflecting real-world likelihoods. We're stating this plainly because it matters: differential privacy is not a free add-on, and any vendor claiming otherwise at meaningful privacy budgets should be asked to show their calibration results, not just their accuracy numbers.
Secure aggregation, simulated via Shamir secret sharing, was utility-neutral when compared against matched differential-privacy-only runs. It did not introduce additional accuracy cost beyond what DP already caused.
Subgroup auditing across payment corridors surfaced a true positive rate gap of 0.797 between corridors, a gap that aggregate accuracy metrics did not show at all. A model that looked strong overall was performing very unevenly underneath. This is the kind of blind spot that matters most in a regulated deployment, and it's why subgroup auditing is a standard part of how Chefoba evaluates any model before deployment, not an optional add-on.
When differential privacy was applied, the measured fairness gap appeared to shrink. Closer inspection showed this was substantially an artefact of degenerate calibration under DP, meaning the model was becoming less discriminative overall rather than genuinely more equitable across subgroups. We flag this specifically because it's an easy result to misreport. A shrinking fairness gap under privacy is not automatically a good sign; it needs to be checked against calibration, not read at face value.
Why we're publishing this
Any platform in this category can claim privacy-preserving collaboration works. We'd rather show you the evaluation, including the parts where privacy techniques cost something real, so your technical and compliance teams can assess the trade-offs themselves before you deploy.
We're onboarding a limited group of fintech and banking partners before general availability.
Join the waitlist