Shared learning does not mean no information moves
A financial institution can possess useful evidence that another institution cannot see. One bank observes repayment behavior, another sees transactions, and a payment network sees connections across accounts. Federated learning organizes model training across distributed datasets. In a common arrangement, each participant performs local calculations and sends model updates for combination rather than transferring its complete raw dataset. NIST distinguishes this approach from centralized training and emphasizes that the data's partitioning changes the technical problem. [1]
The potential benefit is cooperation without creating a single universal customer database. But the model updates are themselves information. A system cannot learn collectively unless something influenced by local data leaves each participant. The relevant privacy question is what that transmitted information reveals, to whom, and under what assumptions about cooperation or attack. Keeping a spreadsheet on its original server is only one part of that answer.
Horizontal and vertical describe different kinds of overlap
Horizontal partitioning means the participants hold different rows with a comparable set of columns. Two lenders might each have repayment histories with the same fields for different customers. Vertical partitioning means participants hold different columns about overlapping entities. A lender might know a loan outcome while another institution holds a different type of information about the same entity. Mixed structures are also possible. [1]
In an invented horizontal example, Bank A has 80,000 loan records and Bank B has 20,000, each with the same feature definitions. A shared model can train locally on each pool and combine updates. If one bank records a at 30 days and the other at 60 days, however, identical column names do not establish a common target. A combined model may interpret a reporting difference as a difference in customer risk.
In an invented vertical example, a payment network and bank must establish which network account corresponds to which bank record before their columns can contribute to one model. A mistaken match joins facts about different entities. An unmatched record loses potentially useful information. Neither problem is solved merely by encrypting the messages. Data alignment has both an accuracy dimension and a privacy dimension.
Aggregation can conceal individual updates
NIST's account of federated averaging describes repeated rounds: a shared model is distributed, participants train locally, and their updates are combined. Basic averaging does not itself provide input privacy because the coordinator receives participant-level updates. Secure aggregation can instead reveal an aggregate while hiding individual contributions under the protocol's assumptions. This addresses exposure of individual updates; it is not a universal guarantee about everything a trained model may reveal. [2]
A small numerical illustration makes the boundary visible. Suppose three invented participants contribute scalar updates of 2, 4 and 9. Their average is 5. If a coordinator learns only that average, it cannot uniquely recover all three numbers from that one equation. But if it separately knows the first two contributions, the third follows: 3 times 5 minus 2 minus 4 equals 9. The illustration is not a cryptographic attack specification; it shows why assumptions about collusion and side information matter.
Participation also changes the operational calculation. If an institution drops out during a round, a protocol may need special handling to complete aggregation while maintaining its guarantees. A design suitable for stable institutional participants can differ from one designed for intermittent phones. Faster communication, fewer rounds and stricter privacy need not improve together. A benchmark speed result is meaningful only with its network, model size and participant assumptions attached.
Joining records can leak information before training begins
NIST's discussion of vertical learning examines private set intersection and Bloom filters as entity-alignment techniques. Depending on the design, intersection methods can reveal information about matching records, while Bloom filters can reveal noisy membership information and produce . Additional protections can reduce exposure at a performance cost. NIST explicitly frames acceptability in terms of the system's threat model rather than describing every such technique as automatically private. [3]
For a hypothetical financial-crime study, the fact that an account appears on another institution's suspicious set could itself be sensitive even if transaction amounts never leave that institution. An accurate membership signal might improve detection while revealing something consequential. A noisy signal may reveal less but can also send investigators toward an innocent account. Privacy and predictive utility are connected through the exact information exchanged.
The same issue applies to missing matches. If one institution learns that a named person is a customer of another, a relationship has been disclosed even without revealing a balance. A technically successful join therefore does not determine whether the institutions are authorized to perform it. This article describes the mechanism and its tradeoffs, not legal permission to share customer information or a finding that a particular implementation complies with financial privacy requirements.
Output protection is a separate layer
Differential privacy can bound an individual's influence on released results under a specified definition and parameter set. In a federated system, its location matters: noise might be added locally, during aggregation or to a released result. NIST SP 800-226 explains that the protected unit and trust model are integral to evaluating the guarantee. Encryption of a message and a bound on what a final model reveals solve different problems. [4]
An invented comparison helps explain the distinction. System A encrypts every update in transit but gives a coordinator the decrypted update for each bank. System B conceals individual updates through secure aggregation. System C adds a carefully defined differential-privacy mechanism to protect against inference from outputs. These descriptions do not prove any system secure; they identify different exposure boundaries. Combining techniques can strengthen protection while adding complexity, computation and statistical noise.
A 2023 financial-anomaly research paper by Kadhe and coauthors combines homomorphic encryption, secure multiparty computation, differential privacy and randomization. The authors analyze a specified honest-but-curious threat model and distinguish input from output protection. That is a research demonstration under stated assumptions, not evidence that every participating institution has deployed the method, that it is regulator-approved, or that it defeats an actively malicious participant. [5]
Institutions can disagree even when the mathematics works
Imagine a consortium in which a large lender supplies 90% of records and two smaller lenders supply the rest. Weighting updates by record count may favor the large lender's population. Giving institutions equal weights changes that objective. Neither weighting rule automatically yields the best performance for every participant. A common model can improve average detection while deteriorating for a smaller institution with a distinctive customer base.
An overall metric can conceal the difference. Suppose an invented fraud model gains two percentage points of recall for the largest participant but loses ten for a small one. The combined average could improve even though that participant has a clear business reason to object. Separate local evaluations would reveal a distribution of benefits that the consortium-wide score hides. This is an incentive problem as well as a model problem.
Malicious or poor-quality contributions add another tension. A participant might supply systematically incorrect labels or attempt to distort the model. Concealing individual updates for privacy can make ordinary inspection of those updates harder. Privacy protection does not, by itself, establish training-data integrity. The threat model determines which behaviors a demonstration has considered and which remain outside its claims.
A bounded form of collaboration
Federated learning can make distributed evidence usable without moving every original record into one repository. Its value is strongest when the institutions have compatible targets, useful complementary information and a clear account of what each participant learns. Shared training can still require common definitions, reliable matching, independent evaluation and sustained operational cooperation.
The enduring distinction is between data location and information disclosure. Local storage changes where records reside. Secure aggregation changes what the coordinator sees. Differential privacy can constrain what outputs reveal. None of those features alone establishes predictive quality or authorization for the activity. Understanding their separate roles makes claims about private financial AI more precise and makes research results easier to compare with real production needs.
Sources
- NIST, Data Distribution in Privacy-Preserving Federated Learning, February 27, 2024Official sourceBack to text: ↑1↑2
- NIST, Protecting Model Updates in Privacy-Preserving Federated Learning, March 21, 2024Official sourceBack to text: ↑
- NIST, Protecting Model Updates in Privacy-Preserving Federated Learning: Part Two, May 2, 2024Official sourceBack to text: ↑
- NIST SP 800-226, Guidelines for Evaluating Differential Privacy Guarantees, March 2025Official source · PDFBack to text: ↑
- Kadhe and coauthors, Privacy-Preserving Federated Learning over Vertically and Horizontally Partitioned Data for Financial Anomaly Detection, October 30, 2023Technical reportBack to text: ↑