WeBank’s AI platform work puts federated learning beside everyday banking engineering

WeBank reports platform development while FATE documents collaborative modelling. The article explains the engineering and human work between those facts and a real collaboration.

Banking data often becomes valuable when it is connected to other information, yet moving it between organisations can create serious privacy and security problems. WeBank's technology work offers a concrete way into that tension. Its public reporting describes a growing internal AI engineering platform, while the FATE project associated with its AI department provides openly documented tools for collaborative machine learning. These are related strands of work, not proof that every application at the bank uses federated learning.

In its [2024 annual report](https://tctp.tctpwebankcdn.net/owb-admin/data/appsystems/owb-admin/1756804158938-13423.pdf), WeBank describes completing an engineering platform covering analytical and generative AI. The technology discussion on PDF page 19 reports more than 221 developed AI applications and an average exceeding 40,000 large-model calls a day. Those are the bank's reported activity measures for that account, not independently measured gains in credit quality, privacy or customer outcomes. The report and technical sources were checked on 16 October 2026.

A platform is the less visible part of the AI story

The report describes attention to model assets, reproducible experiments and pooled computing resources. The significance is operational: an organisation supporting many applications needs repeatable ways to develop, evaluate and maintain them. A model that works in a research notebook still needs a defined input, a deployment route and someone who can respond when its behaviour changes. Application and call counts cannot establish the quality of those processes by themselves.

The everyday banking implications are easy to overlook. If a document-assistance service, a risk model and a customer-support tool all depend on shared infrastructure, maintenance decisions affect several teams. A change to an underlying model or data definition can alter an output even if the visible product looks the same. That creates a need for version ownership, intelligible testing and a way to connect an application to the evidence used to approve its release.

None of this means that centralisation solves every problem. Shared infrastructure can make good practices easier to repeat, but it can also spread a poor assumption. Teams still need to know what the particular application is for and which data it may use. The public annual-report description is evidence of platform work, not a complete technical specification or an independent audit of every application running on it.

Federated learning changes how participants can collaborate

The [FATE documentation for its earlier 1.5 development line](https://fate.readthedocs.io/en/develop-1.5/) identifies the project as initiated by WeBank's AI department. It describes support for federated learning and secure-computation techniques, including homomorphic encryption and multiparty computation. That dated documentation establishes the project's stated origin and technical approach. It does not establish that an arbitrary combination of settings is secure or that a particular bank-to-bank deployment has been authorised.

The broader idea has a research history. [Qiang Yang and co-authors' 2019 paper](https://arxiv.org/abs/1902.04885) distinguishes horizontal, vertical and transfer forms of federated learning. In simple terms, collaborators might hold similar kinds of information about different people, or different kinds of information about overlapping people. Those are different modelling arrangements. The paper supplies a conceptual vocabulary, rather than evidence that a new 2026 banking product is in production.

This distinction matters for a proposed banking collaboration. Two participants may disagree about how a field is defined, how a record is matched or what a missing value means. Keeping raw records in separate systems does not resolve those disagreements. The collaborators still need an agreed task and a permitted relationship between the data. Otherwise the resulting model can be difficult to interpret even if the communication protocol performs exactly as designed.

Open technical components are useful, but they are not a blanket privacy claim

The [FATE 2.0 heterogeneous-neural-network documentation](https://fate.readthedocs.io/en/latest/2.0/fate/components/hetero_nn/) describes a framework built around PyTorch and transformers and offers SSHE and FedPass strategies. It explains that these use different mechanisms: SSHE combines homomorphic encryption with secure sharing, while FedPass uses private passports within the network. These are documented implementation options. They should not be collapsed into one assurance that every form of federated training hides everything from every participant.

There is a specific research reason for that caution. [Deep Leakage from Gradients, a 2019 paper by Ligeng Zhu, Zhijian Liu and Song Han](https://arxiv.org/abs/1906.08935), demonstrated that shared gradients can reveal training information in the authors' experimental settings. That result is not evidence of a breach at WeBank or proof that a particular FATE encrypted protocol is vulnerable. It shows why the information exchanged during training, and the assumptions about who can see it, deserve direct evaluation.

Maintenance adds another layer. The [FATE v 2.2.0 release note](https://github.com/FederatedAI/FATE/releases/tag/v2.2.0) lists changes including a move to Python 3.10 and PyTorch 2.x. A software release demonstrates a particular project's published evolution, not regulatory approval or successful adoption in an institution. Banking teams considering it would need to evaluate the exact version and dependencies they intend to use. This article did not install or run the framework.

For staff, collaborative modelling brings work in coordinating data definitions, reviewing access and reproducing results across organisations. For customers, the possible attraction is that a useful analysis might be developed without pooling all underlying records in one place. That is a potential design benefit, not an established result for the people served by WeBank. The quality, fairness and contestability of a resulting decision still have to be examined separately.

A proposed learning exercise: agree on the meaning before training together

An original learning exercise could give two fictional institutions synthetic records about a small-business application. One holds invented payment history; the other holds invented business characteristics. No real customer data, banking connection or credit decision would be involved. The goal is to explore which questions collaboration might answer and which permissions, definitions and tests it would need before anyone proposes a live model.

The first exercise is deliberately non-technical. Teams define the outcome they want to study and compare the meaning of their fields. A late payment in one dataset might mean a different event from a late payment in the other. A business identifier may refer to an enterprise in one system and an establishment in another. Learners should discover and document those differences before treating records as compatible training material.

Next, the group draws a proposed information-flow diagram. It labels raw records, any matching step, intermediate information, model output and the people or systems able to see each element. The diagram should distinguish assumptions from protections established by a selected protocol. A reviewer asks what an authorised participant could infer, what happens if one participant supplies bad data and how the collaboration would stop or recover after an error.

Finally, participants design an evaluation on synthetic data that compares useful performance with the costs and limitations of the arrangement. They record communication overhead, missing records and whether the result can be explained to a reviewer. No result should be labelled production-ready merely because a tutorial completes. The exercise ends with an explicit list of questions requiring specialist security, privacy and domain review before a real collaboration could proceed.

WeBank's reported platform and the documented FATE ecosystem reveal a banking AI story that is less visible than a customer chatbot but just as practical. The work involves making models repeatable and collaboration intelligible. Open documentation helps readers inspect the proposed mechanisms; it cannot supply the permissions or demonstrate the outcomes of a particular institution's use. That is where the next stage of evidence, and much of the human work, still belongs.

Explanatory diagram and accessible reading guide


*Original educational infographic based on attributed reports and a fictional proposed exercise; not the named bank’s internal architecture, actual customer decision or measured result.*

[Open the full-size explanatory diagram](/assets/bank-china-information-exchange-20261016.svg)

This original diagram explains attributed source context and a fictional learning exercise. The exercise has not been run; the diagram is not an authentic product interface, internal bank architecture or measured operational result.

What is exchanged, and who can see it?

Original learning model for fictional data holders. It is not WeBank architecture, a FATE deployment or privacy certification.

Agreed task and meaning

Clarify the permitted question and what each field means before training.

Fictional holder A

Keep the original source records in this participant's own workspace.

Fictional holder B

Keep the other participant's source records separate.

Select the exact protocol

SSHE and FedPass use different mechanisms. Do not draw one universal privacy shield.

Controlled intermediate exchange

Identify any matching step and intermediate information the chosen protocol reveals.

Evaluate model or output

Test usefulness, overhead and explanation on synthetic data.

Reviewer questions

Who can infer what? What if input is wrong? How would the collaboration stop?

Arrangement choices differ: horizontal uses similar fields for different people; vertical uses different fields for overlapping people. Choose the arrangement and protocol explicitly.

WeBank's 2024 platform report describes over 221 applications and over 40,000 model calls daily. Those activity counts do not count federated deployments or privacy outcomes.

The two holders are parallel participants retaining their source records. Raw-record separation does not by itself establish privacy, permission or decision quality.

Solid arrows show the stated or proposed information handoff. Dashed arrows show an editorial bridge or a return for checking. No arrow proves a measured causal effect.

The agreed task frames one fictional participant's source records.

The same agreed task frames the other fictional participant.

One holder contributes only under an explicitly selected arrangement.

The other holder uses the same agreed protocol boundary.

The protocol determines permitted intermediate exchanges and visibility.

The fictional collaboration proposes an evaluation of the resulting model or output.

Evaluation is incomplete without visibility, bad-input and stopping questions.

Unresolved assurance questions return to protocol and permission review.

Diagram source references

- [S01: \[1902.04885\] Federated Machine Learning: Concept and Applications](https://arxiv.org/abs/1902.04885) — Paper authors via arXiv.

- [S02: \[1906.08935\] Deep Leakage from Gradients](https://arxiv.org/abs/1906.08935) — Paper authors via arXiv.

- [S03: FATE — FATE documentation](https://fate.readthedocs.io/en/develop-1.5/) — FATE project / WeBank.

- [S04: Hetero NN - FATE](https://fate.readthedocs.io/en/latest/2.0/fate/components/hetero_nn/) — FATE project / WeBank.

- [S05: Release Release v2.2.0 · FederatedAI/FATE · GitHub](https://github.com/FederatedAI/FATE/releases/tag/v2.2.0) — FederatedAI/FATE project.

- [S10: WeBank Annual Report2024](https://tctp.tctpwebankcdn.net/owb-admin/data/appsystems/owb-admin/1756804158938-13423.pdf) — WeBank.