Federated Learning in Finance

In a common training arrangement, each institution starts from the same model and trains it on local records. An aggregator combines the resulting updates to produce another version of the shared model. Federated Averaging combines model updates across repeated training rounds, with the model parameters changing as training continues.

For a bank, the local dataset might contain transaction attributes and reviewed fraud outcomes. A shared model could learn from participating institutions without requiring a single central copy of those raw records. The collaboration still needs a defined purpose and consistent rules for preparing the training inputs.

Horizontal federated learning uses similarly structured information about different records held by the participants. Banks might hold the same transaction fields for separate customer populations. Common field definitions allow the institutions to train comparable local models before combining updates.

Vertical federated learning involves different information about overlapping individuals or entities across participants. A financial collaboration must then establish which records belong together without exposing unnecessary identifying information. Mixed arrangements combine both patterns and require a correspondingly careful assessment of the alignment process.

The BIS Innovation Hub tested collaborative methods for detecting money laundering in Project Aurora. Project Aurora used synthetic payment data to compare monitoring approaches across separate institutions and borders. Project Aurora was a proof of concept using machine learning, network analysis and technologies for protecting privacy.

Project Aurora tested federated training with local data to examine data sovereignty within the collaboration. These experimental results do not establish production performance for an individual bank. Network analytics for AML examines financial relationships, while federated learning describes how participants train models across distributed datasets.

Model gradients can reveal information about the underlying training records even when raw customer data remains local. A gradient measures how model error changes when model parameters change. Participants need to assess the information visible to the aggregator and to other parties in their actual arrangement.

The relevant questions include who receives individual updates and who can query the resulting model. Access to successive model versions can also form part of the privacy assessment. A consortium should document the assumed adversaries before choosing controls for its financial datasets.

Secure aggregation can conceal individual model updates from the aggregator while allowing an aggregate result to be computed. The protection depends on the chosen protocol and its assumptions about participating parties. Teams should examine collusion and participant dropout when assessing whether those assumptions fit their collaboration.

Differential privacy adds controlled randomness during training to limit what can be inferred about individual training contributions. The privacy configuration can affect the usefulness of the resulting financial model. Repeated training and model releases require a documented privacy accounting approach and evaluation of detection quality.

Participating banks can differ in customer populations, available history and the way confirmed cases are labeled. A model that improves an aggregate score may still perform poorly for one institution. Evaluation should compare local baselines with the shared model using cases and periods excluded from training.

The model validation process in banking can examine detection quality alongside the workload generated for analysts. Teams should inspect missed cases and the consequences of incorrectly flagged transactions. Data definitions, model versions and the outcome of each evaluation need accountable owners throughout the collaboration.

A proposed pilot can begin with one financial crime question and a limited group of institutions. The participants can define the permitted training inputs and measurable acceptance criteria before exchanging updates. Tests should include a disconnected participant and an update that fails agreed quality checks.

The pilot also needs a decision on model access after training and the handling of later corrections. Each bank should establish how a model result enters its existing investigation process. A decision to use the model in production requires evidence from that operating context.