| Next revision | Previous revision |
| fxdemo:06-part:00-foreword:start [2026/06/26 15:14] – created nick_dido | fxdemo:06-part:00-foreword:start [2026/08/04 07:09] (current) – ↷ Links adapted because of a move operation nick_dido |
|---|
| ====== Introduction ====== | ====== Foreword ====== |
| |
| Financial systems do not process transactions without cost. Each validation step, policy decision, fraud check, anti-money-laundering review, sanctions screen, semantic interpretation, persistence action, replay capability, audit record, and authorised release activity consumes resources and creates operational responsibility. Existing FX systems often recover these costs indirectly through exchange-rate spreads, fees, commissions, internal chargeback models, or bundled service pricing. These mechanisms may hide both the true cost of governed work and the absence of required work. | [[fxdemo:06-part:start|Go to Top]] |
| |
| The FX Demo Reference Architecture treats cost recovery as an architectural concern. A distributed financial system requires a way to identify which Nodes performed governed work, which obligations required that work, which evidence proves that the work occurred, which cost rules apply, and which accounting or settlement artefacts result. Without this visibility, participants cannot reliably distinguish efficient compliant processing from under-compliance. | The [[dido:99_annexes:annex-b-terms-and-definitions:f:foreign_exchange_domain|FX]] Demo [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture]] addresses a distributed [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_system|financial system]] environment in which multiple organizations, jurisdictions, service providers, and oversight bodies participate in the governance of transaction processing. Earlier parts of the document set establish the conceptual foundation, [[dido:99_annexes:annex-b-terms-and-definitions:p:platform_independent_model|Platform Independent Model]], FX Demo logical profile, [[dido:99_annexes:annex-b-terms-and-definitions:p:platform_specific_model|Platform Specific Model]] mapping, and Phase 0 implementation guidance. [[fxdemo:06-part:start]] extends that foundation by addressing the economic accountability of governed work. |
| |
| Part 6 defines the Cost Recovery, Compensation, and Settlement Plane. The plane makes the economic footprint of governed financial processing visible, attributable, auditable, comparable, and recoverable. It supports compensation for qualified Nodes, cost allocation for shared infrastructure, ordinary accounting treatment, and competition among compliant implementations. | Financial processing depends on services that impose real costs. These services include validation, fraud screening, anti-money-laundering review, sanctions checking, [[dido:99_annexes:annex-b-terms-and-definitions:s:semantic|semantic]] interpretation, policy evaluation, persistence, provenance capture, replay support, evidence retention, authorized release, operational monitoring, and exception handling. Existing FX systems often recover these costs through exchange-rate spreads, fees, commissions, bundled service pricing, or internal chargeback models. Those mechanisms may obscure which work was performed, which participant performed it, which [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|evidence]] supports it, and whether the required work occurred. |
| |
| The plane does not require blockchain, speculative tokens, or a separate monetary system. It uses evidence-linked records that support familiar accounting outcomes such as service charges, chargebacks, reimbursements, regulated cost recovery, intercompany allocations, consortium settlement, and infrastructure levies. | Part 6 introduces the [[dido:99_annexes:annex-b-terms-and-definitions:c:cost_recovery_compensation_and_settlement_plane|Cost Recovery, Compensation, and Settlement Plane]] as an architectural mechanism for making governed work economically observable. The plane supports cost attribution, compensation for qualified [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Nodes]], settlement through ordinary accounting mechanisms, competition among compliant implementations, and visibility into missing assurance work. It does not create a blockchain-style payment system, speculative token, or alternative currency. |
| |
| The plane also preserves separation of concerns. Its prices governed work without inspecting unnecessary business content. It may reference transaction identifiers, work types, policy obligations, evidence records, retention periods, data volume bands, and settlement rules, but it does not require routine access to full transaction payloads, detailed AML findings, fraud investigation notes, or regulated data. | The plane also preserves the separation-of-concerns discipline used throughout the FX Demo Reference Architecture. Its prices govern work without requiring unnecessary access to transaction payloads, regulated data, detailed compliance findings, or sensitive business content. It links cost records to obligations and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence_reference|Evidence References]], enabling participants to distinguish low-cost compliant processing from [[dido:99_annexes:annex-b-terms-and-definitions:u:under-compliance|Under-Compliance]]. |
| |
| Part 6 extends the FX Demo document set by showing how governed work becomes economically observable. It connects the Data Plane, Control Plane, Policy and Release Plane, and Persistence and Evidence Plane to cost attribution and settlement outcomes. This strengthens the reference architecture by ensuring that trusted processing, compliance work, evidence retention, and operational assurance do not remain unfunded, hidden, or unverifiable. | Part 6 should be read with the preceding parts of the document set. It depends on the conceptual principles in [[fxdemo:01-part:start]], the platform-independent structures in [[fxdemo:02-part:start]], the FX Demo logical profile in [[fxdemo:03-part:start]], the platform-specific mapping in [[fxdemo:04-part:start]], and the implementation guidance in [[fxdemo:05-part:start]]. It provides the additional architectural treatment needed to show how trusted distributed financial infrastructure remains economically sustainable, auditable, and accountable. |
| |