====== Introduction ====== [[fxdemo:01-part:start | Go to Top ]] [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_system|Financial Systems]] depend on structured information whose meaning must remain stable across institutions, systems, technologies, jurisdictions, and time. These systems process financial facts, control instructions, [[dido:99_annexes:annex-b-terms-and-definitions:i:interpretation|Interpretation]] results, policy decisions, release actions, audit records, provenance records, and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]. The architecture must keep these concerns distinct so [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_system|Financial Systems]] can remain governable, [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceable]], [[dido:99_annexes:annex-b-terms-and-definitions:i:interoperability|Interoperable]], and adaptable. The Financial Systems Archetype applies the SDIS/SIP-RA discipline to the [[dido:99_annexes:annex-b-terms-and-definitions:f:foreign_exchange_domain|Financial Domain]]. Part 0 explains the document set and the onion structure used to separate conceptual architecture, logical architecture, domain profiles, implementation profiles, deployment profiles, testability, and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]. This part defines the conceptual layer at the centre of that onion. This part establishes the concepts that the later parts use to define logical models, domain profiles, implementation mappings, deployment models, and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] plans. It defines the classification model for [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_system|Financial Systems]], including [[dido:99_annexes:annex-b-terms-and-definitions:e:ecosphere|Ecosphere]], [[dido:99_annexes:annex-b-terms-and-definitions:e:ecosystem|Ecosystem]], and [[dido:99_annexes:annex-b-terms-and-definitions:d:domain|Domain]]. It also defines core concepts such as [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Node]], [[dido:99_annexes:annex-b-terms-and-definitions:n:node_role|Node Role]], [[dido:99_annexes:annex-b-terms-and-definitions:n:node_identity|Node Identity]], [[dido:99_annexes:annex-b-terms-and-definitions:c:communication_endpoint|Communication Endpoint]], [[dido:99_annexes:annex-b-terms-and-definitions:d:data_structure_definition|Data Structure Definition]], [[dido:99_annexes:annex-b-terms-and-definitions:d:data_structure_instance|Data Structure Instance]], [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]], [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]], [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]], and Separation of Concerns. This part deliberately avoids technology-specific bindings. Later parts may map a [[dido:99_annexes:annex-b-terms-and-definitions:c:communication_endpoint|Communication Endpoint]] to a DDS Topic, a [[dido:99_annexes:annex-b-terms-and-definitions:d:data_structure_definition|Data Structure Definition]] to an IDL structure, a [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Node]] to a Python process packaged as an OCI-compatible container image, or a deployment profile to Kubernetes or K3s. Those mappings realize the conceptual architecture for a specific purpose. They do not redefine the conceptual architecture. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.