Architecture

2.1 Key System Components

A typical FA deployment includes several core components working together to support secure and governed analysis across multiple participants. These components reflect the main design principles of FA: raw data remains local, computation is performed within each participant environment, only derived outputs are combined, and governance is applied around query execution and result release.

1. Query or submission layer

   This is the interface through which authorised users define and submit analytical queries. Depending on the deployment, queries may be fully custom, parameterised within pre-approved templates, or restricted to a defined library of permitted analyses. In multi-party settings, this layer often also enforces authentication, access controls, and basic validation checks before a query is distributed.

2. Local compute nodes

   Each participating organisation operates a local node with access to its own dataset. These nodes receive approved queries, execute them locally, and produce the required local outputs. Depending on the use case, local computation may involve filtering, grouping, statistical summarisation, or generation of intermediate statistics needed for downstream aggregation. This local execution model allows each participant to retain control over its own data and operating environment.

3. Aggregation layer

   The aggregation layer combines outputs returned by participating nodes into a system-level result. In simpler deployments, this may involve straightforward central aggregation of local statistics. In more sensitive settings, aggregation may be supported by additional privacy-enhancing technologies, such as secure computation or encryption-based techniques, to limit what any coordinating party can observe during the process.

4. Governance and release layer

   Before results are returned to end users, many FA deployments apply a governance or release step. This may include disclosure controls such as minimum thresholds, checks against permitted analytical scope, manual approval workflows, or logging requirements for auditability. In cross-organisational and cross-border settings, this layer is often critical to maintaining trust between participants and ensuring outputs are safe to release.

2.2 Centralised vs Decentralised

FA deployments can be implemented in different ways depending on trust assumptions, governance requirements, and the sensitivity of the data involved. The table below summarises the main architectural patterns and their typical trade-offs.

Name	Description	Commentary
Centralised	A single coordinating service distributes queries, collects local outputs, and aggregates them into a final result.	Usually the most straightforward architecture to implement, monitor, and govern. It supports clearer auditability and more consistent enforcement of query and release policies. Best suited where a trusted or semi-trusted lead party exists. Its main limitation is that the coordinator becomes a central dependency for trust, resilience, and scale.
Decentralised	Participating nodes communicate directly or coordinate through distributed protocols, without relying on a single central orchestrator.	Reduces reliance on a single control point and may be preferable where no one participant is sufficiently trusted to coordinate the process. However, it is generally more complex to design, synchronise, monitor, and govern. In practice, this can make auditability, operational consistency, and troubleshooting more difficult than in centralised approaches.
Secure centralised	A central coordinator manages the workflow, but aggregation is enhanced with Privacy-Preserving Technologies (PETs), such as homomorphic encryption, secure aggregation, or other secure computation methods, to reduce what the coordinator can observe.	Retains the operational simplicity of central orchestration while providing stronger confidentiality protections over intermediate results. This can be useful where a coordinator is needed for governance and usability, but participants require stronger technical safeguards. The trade-off is higher engineering complexity, greater computational overhead, and, depending on the technique used, limits on the types of computations that are practical.