# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-28T10:37:31Z", "synthesisSha256": "9b81399854baa9681071d8b703d4289fe8ef8806ab0c5dc55576bd3e610c7038", "providers": [ "Claude", "Grok" ] }, "metaModel": { "id": "WM-ECO-004", "registryId": "vr.wm-eco-004", "name": "Money / Instrument", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "entity", "family": "World Models", "category": "Society, people and institutions", "industry": [ "Cross-industry" ], "domain": [ "SOC.ECO.MNY" ], "tags": [ "money", "instrument", "soc.eco.mny" ], "status": "research draft" }, "canonicalUrl": "https://ver.cy/models/wm-eco-004-money-instrument/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-eco-004", "model": { "registry_id": "vr.wm-eco-004", "model_id": "WM-ECO-004", "name": "Money / Instrument", "entry_kind": "entity", "purpose": "Define the monetary unit of account and the transferable monetary instrument that denominate, embody and store value, so that any agent can identify a unit or instrument, classify it, reason about its issuer, claim, legal status and lifecycle, and construct or validate a monetary amount without owning accounts, balances or payment execution.", "scope_statement": "WM-ECO-004 owns the referenced thing that money is: (a) the monetary unit of account and its code, denomination structure and lifecycle; (b) the monetary instrument class - the concrete form money takes (banknote, coin, deposit money, electronic money, central bank digital currency, e-money token) with its issuer, claim, backing, redeemability, transferability and settlement-asset character; and (c) the monetary amount value object with its precision, rounding and conversion rules. It does not own accounts, holdings, payment orders, settlement processing or credit claims: those are referenced from sibling models that point at this one. The model is storage- and interface-neutral; ISO 4217 lists, ISO 20022 payloads, DTI registry records, Git files, MCP tools and MongoDB documents are projections of these semantics, not the semantics.", "in_scope": [ "Monetary unit of account: identity, alphabetic and numeric codes, official and local names, symbol and presentation, minor unit and subdivision structure", "Unit kind classification: national currency, supranational currency, fund code, precious-metal unit, special drawing right, special-purpose codes such as no-currency and testing codes, and digital token units", "Monetary instrument class: form taxonomy, fungibility, divisibility, negotiability, bearer versus registered form, ledger or medium dependency", "Issuer identity and issuance authority, the claim the instrument represents, its backing or reserve arrangement, and redemption rights including redemption at par", "Settlement-asset character: central bank money, commercial bank money or other settlement asset, and the instrument's capacity to discharge an obligation with finality", "Legal tender status, territorial and jurisdictional validity, issuer authorisation and supervisory status, and usage or holding restrictions attached to the unit or instrument", "Lifecycle and succession of units and instrument series: introduction, redenomination, currency substitution, withdrawal, demonetisation and exchange windows", "Monetary amount as a value object: amount plus unit reference, permitted scale, sign, rounding and conversion arithmetic, and the provenance and fitness for use of any rate applied", "Governance of the local record: authoritative source, amendment tracking, external code-scheme alignment, validation evidence, publication, retention and access" ], "out_of_scope": [ "Financial accounts, wallets and their holders, scheme membership and account identifiers such as IBAN or BIC - owned by WM-ECO-015", "Balances, holdings, positions and as-of quantification of who holds how much - owned by WM-ECO-017", "Payment orders, initiation, clearing, settlement instruction processing, rails, operating calendars and payment lifecycle status - owned by WM-ECO-009", "Credit and debt claims, principal, interest and amortisation schedules; these reference monetary units but are separate instruments", "Non-monetary financial instruments such as equities, bonds and derivatives identified by ISIN, UPI or CFI", "Legal and natural person identity, organisational structure and beneficial ownership of issuers or holders", "Market microstructure, order books, tradable price discovery and time series of traded FX prices", "Monetary policy operations, money supply aggregates, macroeconomic statistics and national accounts compilation", "Anti-money-laundering screening logic, sanctions list maintenance and transaction monitoring rules" ], "boundary_notes": [ { "neighbor": "WM-ECO-009 Payment / Funds Transfer", "distinction": "WM-ECO-009 owns the transfer event, its parties, instruction, rail and settlement outcome. WM-ECO-004 owns only the unit or instrument that the transfer moves, plus the instrument's intrinsic settlement-asset character. PFMI Principle 8 finality is a property of the transfer arrangement; PFMI Principle 9 money settlement is a property of the settlement asset, so the asset-side attribute stays here and the process stays in WM-ECO-009.", "source_refs": [ "SRC-004", "SRC-005" ] }, { "neighbor": "WM-ECO-015 Financial Account", "distinction": "An account declares its denomination or the monetary instruments it may hold by referencing a WM-ECO-004 unit or instrument. Account identity, parties, scheme, status and access rules are never duplicated here. Account-number schemes are excluded even though they co-occur with currency in ISO 20022 payloads.", "source_refs": [ "SRC-015" ] }, { "neighbor": "WM-ECO-017 Financial Position / Balance", "distinction": "A position quantifies an amount of a referenced unit or instrument at a stated time. WM-ECO-004 supplies the unit reference and the amount value-object rules including scale and rounding; it never records who holds how much. The previous F2 'holding' object is retired from this model's scope.", "source_refs": [ "SRC-015", "SRC-017" ] }, { "neighbor": "Credit and debt claim model (legacy F8)", "distinction": "Deposit money is in scope here as an instrument form classified as a liability of a deposit-taking corporation, following the statistical classification of currency and deposits. Loans, bonds and other credit claims are out of scope even though they are denominated in a monetary unit and settled by payments in one.", "source_refs": [ "SRC-017", "SRC-018" ] }, { "neighbor": "Market price / FX market data model", "distinction": "WM-ECO-004 keeps only the definitional side of conversion: the ordered currency pair, the quotation convention, legally fixed conversion rates and the provenance of any referenced rate. Continuous market price discovery, tradable quotes and rate time series belong to a market-data sibling; the ECB reference rates are explicitly not intended for transaction purposes, which shows the two concerns must not be merged.", "source_refs": [ "SRC-010", "SRC-013" ] }, { "neighbor": "Organization / legal entity model", "distinction": "Issuers, maintenance agencies and registration authorities are referenced by governed entity identifier such as an LEI. Their corporate identity, hierarchy and relationship data stay in the organization model; only the issuance role and its authorisation evidence are asserted here.", "source_refs": [ "SRC-006" ] }, { "neighbor": "Jurisdiction / place model", "distinction": "Territorial validity, legal tender scope and monetary sovereignty are expressed as references to jurisdiction entities. The definition, geometry and political status of those jurisdictions are not modelled here, which matters because a unit can be lawful money in jurisdictions that did not issue it.", "source_refs": [ "SRC-014", "SRC-020" ] }, { "neighbor": "Securities and non-monetary instrument model", "distinction": "ISO 4217 also carries fund codes and precious-metal codes that are not currencies, and DTI covers tokens that are securities rather than money. WM-ECO-004 includes such codes only as unit-of-account references and marks them as non-monetary; the instruments they identify belong elsewhere.", "source_refs": [ "SRC-003", "SRC-008" ] } ] }, "sources": [ { "id": "SRC-001", "title": "Financial Data Standards - ISO 4217 (Currency codes)", "organization": "SIX Group AG (Maintenance Agency Secretariat for ISO 4217)", "url": "https://www.six-group.com/en/products-services/financial-information/data-standards.html", "version_or_date": "Code lists as published August 2026; latest amendment 180 effective 2026-01-01", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:05:00Z", "relevance": "Authoritative publication point for ISO 4217 alphabetic code, numeric code, minor unit and entity; defines List One current codes, List Two fund codes and List Three historic codes and the amendment process." }, { "id": "SRC-002", "title": "ISO 4217 Amendment Number 180", "organization": "SIX Group AG", "url": "https://www.six-group.com/dam/download/financial-information/data-center/iso-currrency/amendments/dl-currency-iso-amendment-180.pdf", "version_or_date": "Amendment 180, effective 2026-01-01", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:07:00Z", "relevance": "Concrete evidence of unit succession: Bulgaria moves from BGN to EUR (numeric 978, minor unit 2), demonstrating amendment numbering, effective dating and migration of a code to the historic list." }, { "id": "SRC-003", "title": "ISO 4217:2015 Codes for the representation of currencies", "organization": "International Organization for Standardization", "url": "https://www.iso.org/standard/64758.html", "version_or_date": "Edition 8, 2015 (current at access date)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:10:00Z", "relevance": "Normative structure of the three-letter alphabetic and three-digit numeric currency code, and the explicit inclusion of funds and precious metals in scope alongside currencies." }, { "id": "SRC-004", "title": "Principles for financial market infrastructures", "organization": "Committee on Payments and Market Infrastructures (BIS) and IOSCO", "url": "https://www.bis.org/cpmi/publ/d101a.pdf", "version_or_date": "April 2012", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:12:00Z", "relevance": "Principle 8 settlement finality and Principle 9 money settlements; the normative distinction between central bank money and commercial bank money as settlement assets, and the credit and liquidity risk attaching to each." }, { "id": "SRC-005", "title": "Application of the Principles for Financial Market Infrastructures to stablecoin arrangements", "organization": "Committee on Payments and Market Infrastructures (BIS) and IOSCO", "url": "https://www.bis.org/cpmi/publ/d206.htm", "version_or_date": "July 2022", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:14:00Z", "relevance": "Establishes that a settlement asset may be neither central bank nor commercial bank money, and that such assets carry additional financial risk - the basis for a third settlement-asset class in this model." }, { "id": "SRC-006", "title": "Introducing the Legal Entity Identifier (LEI)", "organization": "Global Legal Entity Identifier Foundation (GLEIF)", "url": "https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei", "version_or_date": "Accessed 2026-08-28; identifier standard ISO 17442", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:16:00Z", "relevance": "Governed 20-character global identifier for the issuing legal entity, with Level 1 and Level 2 reference data, free public access and a defined issuer and oversight chain (GLEIF, ROC, LOUs)." }, { "id": "SRC-007", "title": "Digital Token Identifier Foundation - Registration Authority for ISO 24165", "organization": "Digital Token Identifier Foundation (DTIF), a division of Etrading Software", "url": "https://dtif.org/", "version_or_date": "Accessed 2026-08-28", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:18:00Z", "relevance": "Registration authority for the Digital Token Identifier; states the DTI is open and freely reusable, and publishes a registry with API, schema explorer and bulk download - the identifier of record for digital token units." }, { "id": "SRC-008", "title": "ISO 24165-2:2025 Digital token identifier (DTI) - Registration, assignment and structure - Part 2: Data elements", "organization": "International Organization for Standardization", "url": "https://www.iso.org/standard/85547.html", "version_or_date": "2025 edition", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:20:00Z", "relevance": "Defines the data elements recorded for a digital token and separates token identifiers from digital ledger identifiers, extending coverage to fungible and non-fungible tokens." }, { "id": "SRC-009", "title": "Euro banknotes", "organization": "European Central Bank", "url": "https://www.ecb.europa.eu/euro/banknotes/html/index.en.html", "version_or_date": "Accessed 2026-08-28", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:22:00Z", "relevance": "First-party evidence of instrument series (first series and Europa series), denomination sets, discontinued issuance of the EUR 500 note, and the ECB plus national central bank issuance arrangement." }, { "id": "SRC-010", "title": "Euro foreign exchange reference rates", "organization": "European Central Bank", "url": "https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html", "version_or_date": "Rates dated 2026-08-27; published each TARGET working day around 16:00 CET", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:24:00Z", "relevance": "Model case for rate provenance and fitness for use: publication time and time zone, concertation procedure, explicit caveat that use for transaction purposes is discouraged, and suspension of a pair (EUR/RUB) when representative rates cannot be established." }, { "id": "SRC-011", "title": "Directive 2009/110/EC on the taking up, pursuit and prudential supervision of the business of electronic money institutions", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/eli/dir/2009/110/oj/eng", "version_or_date": "OJ L 267, 10.10.2009 (consolidated text)", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:26:00Z", "relevance": "Legal definition of electronic money as a stored monetary value representing a claim on the issuer, issued on receipt of funds, together with issuance at par and redeemability obligations and the electronic money issuer concept." }, { "id": "SRC-012", "title": "Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA)", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/eli/reg/2023/1114/oj/eng", "version_or_date": "Adopted 31 May 2023; OJ L 150, 9.6.2023", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:28:00Z", "relevance": "Defines crypto-asset as a digital representation of value or rights transferable and stored electronically, and separates electronic money tokens referencing a single official currency from asset-referenced tokens referencing other values - the classification split this model adopts for token units." }, { "id": "SRC-013", "title": "Council Regulation (EC) No 1103/97 on certain provisions relating to the introduction of the euro", "organization": "Council of the European Union", "url": "https://eur-lex.europa.eu/eli/reg/1997/1103/oj/eng", "version_or_date": "OJ L 162, 19.6.1997", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:30:00Z", "relevance": "Normative conversion arithmetic: conversion rates adopted with six significant figures, prohibition on rounding or truncating the rate, prohibition on using derived inverse rates, and the round-half-up rule for converted amounts." }, { "id": "SRC-014", "title": "Council Regulation (EC) No 974/98 on the introduction of the euro", "organization": "Council of the European Union", "url": "https://eur-lex.europa.eu/eli/reg/1998/974/oj/eng", "version_or_date": "OJ L 139, 11.5.1998 (consolidated)", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:32:00Z", "relevance": "Substitution of national currency units by the euro, legal tender status of euro coins and the limit on obligatory acceptance of more than fifty coins in a single payment - evidence that legal tender is bounded, not absolute." }, { "id": "SRC-015", "title": "The ISO 20022 Repository", "organization": "ISO 20022 Registration Authority", "url": "https://www.iso20022.org/financial-repository", "version_or_date": "Accessed 2026-08-28; repository under release control with periodic maintenance", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:34:00Z", "relevance": "Business Process Catalogue and Data Dictionary containing business concepts, message concepts and data types; the syntax-independent modelling approach and externalised code sets that this model aligns to for amount and currency representation." }, { "id": "SRC-016", "title": "High-level Recommendations for the Regulation, Supervision and Oversight of Global Stablecoin Arrangements: Final report", "organization": "Financial Stability Board", "url": "https://www.fsb.org/uploads/P170723-3.pdf", "version_or_date": "17 July 2023", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:36:00Z", "relevance": "Requirements for a robust legal claim against the issuer or reserve assets, redemption at par into fiat for single-currency arrangements, unencumbered and readily convertible reserve assets, and an effective stabilisation mechanism." }, { "id": "SRC-017", "title": "Monetary and Financial Statistics Manual and Compilation Guide, Chapter 4: Classification of Financial Assets and Liabilities", "organization": "International Monetary Fund", "url": "https://www.imf.org/external/pubs/ft/mfsmcg/c4.pdf", "version_or_date": "2016 edition", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:38:00Z", "relevance": "Statistical classification separating monetary gold and SDRs from currency and deposits, and defining currency as notes and coin of fixed nominal value that are liabilities of the issuer, with transferable and other deposits distinguished." }, { "id": "SRC-018", "title": "IAS 32 Financial Instruments: Presentation", "organization": "IFRS Foundation / International Accounting Standards Board", "url": "https://www.ifrs.org/issued-standards/list-of-standards/ias-32-financial-instruments-presentation/", "version_or_date": "As issued, accessed 2026-08-28", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-28T09:40:00Z", "relevance": "Defines a financial instrument as a contract giving rise to a financial asset of one entity and a financial liability or equity instrument of another, and classifies cash itself as a financial asset - the accounting anchor for the claim structure of money." }, { "id": "SRC-019", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force", "url": "https://www.rfc-editor.org/rfc/rfc3339", "version_or_date": "July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:42:00Z", "relevance": "Normative timestamp format with mandatory seconds and a required time offset of Z or plus/minus hh:mm, and the explicit rejection of unqualified local time - the basis for this model's temporal rule." }, { "id": "SRC-020", "title": "The euro as legal tender", "organization": "European Commission, Directorate-General for Economic and Financial Affairs", "url": "https://economy-finance.ec.europa.eu/euro/use-euro/euro-legal-tender_en", "version_or_date": "Accessed 2026-08-28; cites Recommendation 2010/191/EU and 2021 Court of Justice judgment", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:44:00Z", "relevance": "Legal tender entails mandatory acceptance at full face value with power to discharge a payment obligation, subject to good-faith refusal, contractual agreement on other means and anti-money-laundering limits." }, { "id": "SRC-021", "title": "Central bank digital currencies: foundational principles and core features", "organization": "Bank of Canada, ECB, Bank of Japan, Sveriges Riksbank, Swiss National Bank, Bank of England, Board of Governors of the Federal Reserve System and Bank for International Settlements", "url": "https://www.bis.org/publ/othp33.htm", "version_or_date": "9 October 2020", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T09:46:00Z", "relevance": "Establishes CBDC as a distinct instrument form that must coexist with cash and other money, be underpinned by a clear legal framework and appropriate standards, and be resilient, secure and low cost to end users." }, { "id": "SRC-022", "title": "ISO 4217 currency code lists maintained by SIX as official Maintenance Agency", "organization": "SIX Group on behalf of ISO and SNV", "url": "https://www.six-group.com/en/products-services/financial-information/market-reference-data/data-standards.html", "version_or_date": "List One / List Three current as of 2026-01-01 amendment (Bulgaria euro changeover)", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T00:00:00Z", "relevance": "Authoritative current, funds and historic lists, including List One XLS/XML and amendment 180 for EUR/BGN dual circulation." }, { "id": "SRC-023", "title": "Central bank digital currencies – FSI Executive Summary", "organization": "Bank for International Settlements, Financial Stability Institute", "url": "https://www.bis.org/fsi/fsisummaries/cbdcs.htm", "version_or_date": "2023-08-31", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T00:00:00Z", "relevance": "Public versus private money; CBDC as a direct central-bank liability; retail versus wholesale CBDC; tokenisation." }, { "id": "SRC-024", "title": "Legal issues relating to the introduction of a retail central bank digital currency (legal aspects of money, currency and legal tender)", "organization": "Bank for International Settlements", "url": "https://www.bis.org/publ/othp88_legal.pdf", "version_or_date": "2024", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T00:00:00Z", "relevance": "Legal distinction among money, currency and legal tender; cash, deposits and e-money as monetary asset classes; nemo dat exception for currency." }, { "id": "SRC-025", "title": "Financial Production, Flows and Stocks in the System of National Accounts (2008 SNA instrument classes)", "organization": "United Nations Statistics Division", "url": "https://unstats.un.org/unsd/nationalaccount/docs/financialhb.pdf", "version_or_date": "Handbook implementing 2008 SNA AF1/AF2 classes", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T00:00:00Z", "relevance": "AF11 monetary gold, AF12 SDRs, AF21 currency, AF22 transferable deposits, AF29 other deposits." }, { "id": "SRC-026", "title": "FATF virtual assets topic page and Glossary definition of virtual asset", "organization": "Financial Action Task Force", "url": "https://www.fatf-gafi.org/en/topics/virtual-assets.html", "version_or_date": "Glossary definition adopted October 2018; topic page current 2024 targeted update", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T00:00:00Z", "relevance": "Virtual asset is a digital representation of value that can be traded, transferred or used for payment and does not include digital representations of fiat currencies already covered elsewhere in the FATF Recommendations." }, { "id": "SRC-027", "title": "Directive 2009/110/EC of the European Parliament and of the Council of 16 September 2009 (Electronic Money Directive)", "organization": "European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0110", "version_or_date": "2009-09-16, Article 2 definition; issuance and redeemability in Title III", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T00:00:00Z", "relevance": "Electronic money as electronically stored monetary value representing a claim on the issuer, issued on receipt of funds, accepted by a person other than the issuer. Official text also published at https://www.legislation.gov.uk/eudr/2009/110/article/2" }, { "id": "SRC-028", "title": "IMF Factsheet: Special Drawing Rights (SDR)", "organization": "International Monetary Fund", "url": "https://www.imf.org/en/About/Factsheets/Sheets/2023/special-drawing-rights-sdr", "version_or_date": "Factsheet dated 2023-10-06; Articles of Agreement SDR Department", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T00:00:00Z", "relevance": "SDR is not a currency; it is a reserve asset and the IMF unit of account based on a five-currency basket; private parties cannot hold SDRs. Companion FAQ: https://www.imf.org/en/About/FAQ/special-drawing-right" }, { "id": "SRC-029", "title": "ISO 20022 external code sets (Registration Authority catalogue)", "organization": "ISO 20022 Registration Authority", "url": "https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-sets", "version_or_date": "Quarterly external code-set publication; February 2026 v1 listed", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-28T00:00:00Z", "relevance": "Payment-message code sets are a sibling concern; ActiveOrHistoricCurrencyCode in ISO 20022 is an alignment of ISO 4217, not a second master for the unit." } ], "structure": { "bundles": [ { "id": "unit-of-account", "name": "Unit of Account", "description": "The monetary unit itself: how it is identified, what kind of unit it is, how it subdivides, and how it is named and presented. This bundle is the referenceable anchor that every sibling model points at when it says 'denominated in'.", "rationale": "ISO 4217 governs the identification and minor-unit structure of currencies, funds and precious metals, and ISO 24165 governs digital token units. Both are external registries with their own maintenance cycles, so the unit must be a first-class referenced entity rather than an inline string on payments or balances.", "source_refs": [ "SRC-001", "SRC-003", "SRC-007", "SRC-008" ], "layers": [ { "id": "unit-identity-and-codes", "name": "Unit Identity and Codes", "description": "Identifying a monetary unit unambiguously and classifying what kind of unit it is, including units that are not currencies at all.", "source_refs": [ "SRC-001", "SRC-003", "SRC-008" ], "findings": [ { "id": "monetary-unit-identity", "name": "Monetary unit identity and identifier priority", "description": "A monetary unit is identified by the authoritative registry identifier of its governing scheme before any locally assigned surrogate. For currencies, funds and precious metals this is the ISO 4217 alphabetic code with its numeric code, published by the Maintenance Agency Secretariat; for digital token units it is the nine-character Digital Token Identifier assigned by the DTI Foundation. Alphabetic codes are reused across time after a unit is withdrawn, so a code alone is not a durable key without a scheme and validity interval.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-007", "SRC-008" ], "questions": [ { "id": "unit-authoritative-identifier", "text": "Which authoritative scheme identifier designates this monetary unit, and what is the code value within that scheme?", "kind": "identity", "answer_data": [ "Code scheme reference (currency code scheme, digital token identifier scheme, national scheme)", "Alphabetic code value", "Numeric code value where the scheme defines one", "Scheme version or amendment reference under which the value is asserted" ] }, { "id": "unit-surrogate-key-basis", "text": "When no governed external identifier exists, what surrogate key is assigned and how is its collision resistance and reuse policy defined?", "kind": "identity", "answer_data": [ "Surrogate identifier value (UUID or ULID)", "Assigning Dimension namespace", "Statement of why no governed identifier applies", "Reuse and retirement policy for the surrogate" ] }, { "id": "unit-code-reuse-disambiguation", "text": "How is a reused or historically ambiguous code disambiguated between distinct units that carried the same alphabetic code at different times?", "kind": "temporal", "answer_data": [ "Validity interval start and end as RFC 3339 timestamps", "Predecessor and successor unit references", "Historic-list membership flag", "Discriminating attributes such as issuing entity and minor unit" ] }, { "id": "unit-non-currency-flag", "text": "Does this identifier denote money, or a fund, precious metal or testing placeholder that must never be treated as spendable money?", "kind": "classification", "answer_data": [ "Monetary versus non-monetary flag", "Reason code for non-monetary status", "Downstream handling constraint" ] } ], "data_elements": [ { "id": "unit-identifier", "name": "unitIdentifier", "description": "Primary identifier of the monetary unit within its governing scheme.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "unit-code-scheme-ref", "name": "unitCodeSchemeRef", "description": "Reference to the governing code scheme and the scheme version or amendment under which the identifier is asserted.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "unit-numeric-code", "name": "unitNumericCode", "description": "Three-digit numeric code where the governing scheme defines one, used for systems that cannot carry alphabetic codes.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "unit-alternate-identifiers", "name": "unitAlternateIdentifiers", "description": "Other identifiers under which the same unit is known in national or proprietary schemes, each carrying its scheme reference.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-008" ] } ], "artifacts": [ { "id": "unit-reference-record", "name": "Monetary unit reference record", "description": "The canonical record for one monetary unit, carrying its scheme identifiers, validity interval, kind classification and the amendment reference that last changed it.", "media_or_form": [ "structured record", "registry entry", "reference dataset row" ], "serial": false, "identity_strategy": "Keyed by governing scheme identifier plus validity interval; a locally assigned ULID is added only when the unit has no governed external identifier.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "unit-kind-classification", "name": "Monetary unit kind and monetary character", "description": "Units carried by the same code scheme are not homogeneous. ISO 4217 covers national and supranational currencies, fund codes and precious-metal units, plus a code reserved for transactions where no currency is involved and a code reserved for testing. Statistical classification separates monetary gold and special drawing rights from currency and deposits. Under MiCA, digital units divide into electronic money tokens referencing a single official currency and asset-referenced tokens referencing other values. An agent must know which of these it holds before treating a value as money.", "source_refs": [ "SRC-003", "SRC-012", "SRC-017" ], "questions": [ { "id": "unit-kind-assignment", "text": "Which unit kind does this record assert - national currency, supranational currency, fund unit, precious-metal unit, special drawing right, special-purpose code or digital token unit?", "kind": "classification", "answer_data": [ "Unit kind code from a controlled vocabulary", "Assigning taxonomy reference", "Evidence reference supporting the assignment" ] }, { "id": "unit-token-subclass", "text": "For a digital token unit, does it reference a single official currency, a basket or other value, or nothing at all, and which regulatory subclass follows?", "kind": "classification", "answer_data": [ "Reference asset or basket composition", "Regulatory subclass such as electronic money token or asset-referenced token", "Jurisdiction in which the subclass determination holds" ] }, { "id": "unit-special-code-semantics", "text": "What semantics apply when a special-purpose code is present, and which operations must be blocked?", "kind": "constraint", "answer_data": [ "Special-purpose code value", "Permitted contexts", "Blocked operations such as amount arithmetic, conversion or settlement" ] }, { "id": "unit-classification-conflict", "text": "Where two authorities classify the same unit differently, which classification governs for a given consumer?", "kind": "exception", "answer_data": [ "Competing classification values with their authorities", "Precedence rule and its basis", "Consumer scope to which each classification applies" ] } ], "data_elements": [ { "id": "unit-kind", "name": "unitKind", "description": "Controlled classification of the unit: national currency, supranational currency, fund, precious metal, special drawing right, special-purpose code or digital token unit.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-017" ] }, { "id": "unit-reference-asset", "name": "unitReferenceAsset", "description": "For a token or fund unit, the asset, currency or basket whose value the unit references.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-016" ] }, { "id": "unit-monetary-character", "name": "unitMonetaryCharacter", "description": "Whether the unit functions as money in the asserting context, as opposed to a commodity, statistical or placeholder unit.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-017" ] } ], "artifacts": [], "inline_only_rationale": "Unit kind is a set of coded attributes evaluated inline on the unit reference record rather than a separately produced artefact; the underlying taxonomies are externally governed by ISO 4217, MiCA and statistical manuals and are referenced by scheme and version rather than reproduced as a local artefact." }, { "id": "sdr-unit-and-reserve", "name": "SDR as unit of account and reserve asset", "description": "The SDR is not a currency and not a claim on the IMF. It is an international reserve asset whose value is based on a basket of five currencies (USD, EUR, CNY, JPY, GBP) and it is the unit of account of the IMF and some other international organizations. Only IMF members, the IMF and prescribed official holders may hold SDRs; private persons cannot. 2008 SNA classifies SDRs as AF12. ISO 4217 lists XDR as a code for the SDR. Basket weights and daily valuation are properties of the unit, not market FX quotes owned by this model as a price series.", "source_refs": [ "SRC-028", "SRC-003", "SRC-025" ], "questions": [ { "id": "sdr-unit-and-reserve-q01", "text": "Is this unit the SDR (XDR), another currency basket, or an ordinary national unit?", "kind": "identity", "answer_data": [ "alphabetic_code", "unit_kind", "sna_class" ] }, { "id": "sdr-unit-and-reserve-q02", "text": "Which listed currencies and fixed amounts compose the SDR or other basket, and who may change that composition?", "kind": "composition", "answer_data": [ "basket_currency_codes", "basket_weights_or_amounts", "basket_review_authority_ref" ] }, { "id": "sdr-unit-and-reserve-q03", "text": "Which classes of holder are legally eligible to hold this reserve instrument, and are private parties excluded?", "kind": "ownership", "answer_data": [ "eligible_holder_class", "prescribed_holder_refs" ] } ], "data_elements": [ { "id": "sdr-unit-and-reserve-data01", "name": "alphabetic_code", "description": "XDR when listed", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-028" ] }, { "id": "sdr-unit-and-reserve-data02", "name": "basket_currency_codes", "description": "Currencies in the valuation basket, as ISO 4217 codes", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028" ] }, { "id": "sdr-unit-and-reserve-data03", "name": "basket_weights_or_amounts", "description": "IMF-fixed currency amounts in the basket", "value_kind": "number", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028" ] }, { "id": "sdr-unit-and-reserve-data04", "name": "eligible_holder_class", "description": "IMF member, prescribed holder, private-ineligible", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-028" ] }, { "id": "sdr-unit-and-reserve-data05", "name": "sna_class", "description": "AF12", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-025" ] } ], "artifacts": [ { "id": "sdr-unit-and-reserve-artifact01", "name": "IMF SDR factsheet", "description": "Defines SDR as reserve asset and unit of account, not a currency.", "media_or_form": [ "authority-notice" ], "serial": false, "identity_strategy": "Identified by the publishing authority and the factsheet publication date.", "source_refs": [ "SRC-028" ] } ], "inline_only_rationale": null } ] }, { "id": "unit-denomination-structure", "name": "Denomination Structure and Presentation", "description": "How a unit subdivides into minor units and how it is officially named, symbolised and rendered for humans without those renderings becoming semantics.", "source_refs": [ "SRC-001", "SRC-003", "SRC-015" ], "findings": [ { "id": "minor-unit-and-subdivision", "name": "Minor unit exponent and subdivision structure", "description": "The governing scheme publishes a minor unit value that fixes the number of decimal places in which amounts of the unit are normally expressed. The value is not universally two: some units have zero decimal places, some have three, and some entries have no applicable minor unit at all, notably precious metals and fund codes. Minor unit is a property of the unit, not of a payment or an account, and it constrains the scale of every amount denominated in that unit.", "source_refs": [ "SRC-001", "SRC-003", "SRC-015" ], "questions": [ { "id": "minor-unit-value", "text": "What minor unit value does the governing scheme publish for this unit, and is it defined at all?", "kind": "measurement", "answer_data": [ "Minor unit exponent as an integer", "Not-applicable indicator where the scheme defines none", "Scheme version from which the value was read" ] }, { "id": "minor-unit-effective-window", "text": "From which effective instant does the current minor unit apply, and what value applied before it?", "kind": "temporal", "answer_data": [ "Effective-from timestamp", "Prior minor unit value", "Amendment reference that changed it" ] }, { "id": "minor-unit-vs-payload-scale", "text": "When a target payload permits more or fewer fractional digits than the minor unit, which constraint governs and how is the divergence recorded?", "kind": "interoperability", "answer_data": [ "Payload scale constraint", "Governing precedence rule", "Divergence record with justification" ] }, { "id": "subdivision-naming", "text": "What is the named subdivision of the unit and does any non-decimal or legacy subdivision remain in force?", "kind": "definition", "answer_data": [ "Subdivision name and ratio to the major unit", "Non-decimal subdivision description where applicable", "Status of the subdivision (current, ceremonial, withdrawn)" ] } ], "data_elements": [ { "id": "unit-minor-unit-exponent", "name": "unitMinorUnitExponent", "description": "Number of decimal places in which amounts of the unit are normally expressed, or an explicit not-applicable marker.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "unit-subdivision-name", "name": "unitSubdivisionName", "description": "Name of the minor denomination of the unit where one exists.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "unit-scale-effective-from", "name": "unitScaleEffectiveFrom", "description": "Instant from which the recorded minor unit value applies, expressed as an RFC 3339 timestamp with offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-019" ] } ], "artifacts": [ { "id": "denomination-profile", "name": "Denomination profile", "description": "A resolved profile per unit giving the effective minor unit, permitted amount scale, the payload scale constraints of each target interoperability profile and the governing precedence when they diverge.", "media_or_form": [ "structured record", "validation profile" ], "serial": false, "identity_strategy": "Keyed by unit identifier plus effective-from instant; superseded profiles are retained rather than overwritten.", "source_refs": [ "SRC-001", "SRC-003", "SRC-015" ] } ], "inline_only_rationale": null }, { "id": "unit-naming-and-presentation", "name": "Official naming, symbol and presentation", "description": "A unit carries an official name in the language of its issuing authority, one or more local or transliterated names, and often a symbol. Presentation - symbol placement, digit grouping, negative-amount styling and the choice between symbol and code - is locale-dependent and must not be confused with the unit's semantics. Storing a rendered string in place of a code destroys the ability to reason about the unit.", "source_refs": [ "SRC-001", "SRC-009", "SRC-015" ], "questions": [ { "id": "unit-official-name-authority", "text": "What is the official name of the unit and which authority is the source of that name?", "kind": "authority", "answer_data": [ "Official name string with language tag", "Naming authority reference", "Source publication and its date" ] }, { "id": "unit-local-names", "text": "Which local, plural or transliterated names and scripts are in authorised use for this unit?", "kind": "definition", "answer_data": [ "Name variants with language and script tags", "Authorisation basis for each variant", "Deprecated variants and the date they were deprecated" ] }, { "id": "unit-symbol-ambiguity", "text": "Which symbol is associated with the unit, and how is it disambiguated where the same symbol serves several units?", "kind": "quality", "answer_data": [ "Symbol characters with code points", "Ambiguity flag and competing units", "Disambiguation rule such as mandatory code qualification" ] }, { "id": "unit-presentation-separation", "text": "How does the record keep locale presentation separate from the stored value so that formatting never becomes the source of truth?", "kind": "interoperability", "answer_data": [ "Stored canonical form", "Presentation profile reference by locale", "Rule prohibiting parsing of rendered strings back into values" ] } ], "data_elements": [ { "id": "unit-official-name", "name": "unitOfficialName", "description": "Official name of the unit with language tag, as published by the naming authority.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "unit-symbol", "name": "unitSymbol", "description": "Symbol or symbols conventionally used for the unit, recorded with code points and an ambiguity indicator.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "unit-presentation-profile-ref", "name": "unitPresentationProfileRef", "description": "Reference to a locale presentation profile governing rendering, explicitly non-semantic.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] } ], "artifacts": [], "inline_only_rationale": "Names and symbols are inline attributes of the unit reference record; locale rendering rules are governed by external locale repositories and are referenced rather than reproduced, so no separately governed artefact is produced by this model." } ] } ] }, { "id": "monetary-instrument", "name": "Monetary Instrument", "description": "The concrete form money takes, treated as a class rather than a holding: its taxonomy, transferability, issuer, the claim and backing behind it, and its character as a settlement asset capable of discharging an obligation.", "rationale": "Statistical classification distinguishes currency from transferable and other deposits; accounting standards treat cash and contractual claims as financial assets with a counterparty; PFMI distinguishes central bank money from commercial bank money as settlement assets; and stablecoin guidance recognises assets that are neither. These are attributes of the instrument, independent of who holds it and independent of any particular transfer.", "source_refs": [ "SRC-004", "SRC-005", "SRC-011", "SRC-017", "SRC-018", "SRC-021" ], "layers": [ { "id": "instrument-classification", "name": "Instrument Form and Transferability", "description": "What kind of instrument this is and how value in it can move, including the medium or ledger the instrument depends on.", "source_refs": [ "SRC-011", "SRC-012", "SRC-017", "SRC-021" ], "findings": [ { "id": "instrument-form-taxonomy", "name": "Instrument form taxonomy", "description": "Monetary instruments divide by form: physical currency in notes and coin of fixed nominal value that are liabilities of the issuer; transferable deposits exchangeable on demand at par and directly usable for payment; other deposits that are not directly transferable; electronic money as stored monetary value representing a claim on the issuer and issued on receipt of funds; central bank digital currency as a distinct central bank liability intended to coexist with cash; and tokenised units such as electronic money tokens and asset-referenced tokens. Each form carries different claim, transfer and risk properties.", "source_refs": [ "SRC-011", "SRC-012", "SRC-017", "SRC-021" ], "questions": [ { "id": "instrument-form-code", "text": "Which instrument form does this class assert, and against which taxonomy is that form defined?", "kind": "classification", "answer_data": [ "Instrument form code", "Taxonomy reference and version", "Distinguishing criteria satisfied" ] }, { "id": "instrument-denomination-unit-link", "text": "Which monetary unit denominates this instrument, and can a single instrument class be denominated in more than one unit?", "kind": "relationship", "answer_data": [ "Denomination unit reference", "Multi-denomination indicator", "Rule for units permitted per instrument class" ] }, { "id": "instrument-medium-dependency", "text": "On what medium, ledger or infrastructure does the instrument's existence depend, and what happens to the instrument if that medium ceases?", "kind": "composition", "answer_data": [ "Medium or ledger reference including digital ledger identifier where applicable", "Dependency criticality", "Contingency or migration provision" ] }, { "id": "instrument-form-boundary-test", "text": "What test distinguishes this instrument from a non-monetary claim such as a loan, voucher, loyalty balance or security token?", "kind": "definition", "answer_data": [ "Inclusion test applied", "Exclusion criteria and the sibling model that would own the excluded case", "Evidence supporting the boundary decision" ] } ], "data_elements": [ { "id": "instrument-form", "name": "instrumentForm", "description": "Coded form of the monetary instrument within the governing taxonomy.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-017" ] }, { "id": "instrument-denomination-unit-ref", "name": "instrumentDenominationUnitRef", "description": "Reference to the monetary unit in which the instrument is denominated.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-017" ] }, { "id": "instrument-ledger-ref", "name": "instrumentLedgerRef", "description": "Reference to the digital ledger or physical medium on which the instrument exists, where the instrument is medium-dependent.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "instrument-class-specification", "name": "Instrument class specification", "description": "The governed description of one monetary instrument class: form, denominating unit, medium dependency, transfer properties, issuer reference and the evidence supporting its classification.", "media_or_form": [ "specification document", "structured record" ], "serial": false, "identity_strategy": "Keyed by issuer identifier plus instrument class identifier; where the class is a registered token, the Digital Token Identifier is the primary key.", "source_refs": [ "SRC-007", "SRC-011", "SRC-017" ] } ], "inline_only_rationale": null }, { "id": "instrument-transferability", "name": "Transferability, fungibility and divisibility", "description": "Whether and how value in the instrument can pass from one party to another: bearer versus registered form, negotiability, fungibility between units of the same class, divisibility down to the minor unit or below, offline transferability, and whether transfer requires the issuer's or an operator's participation. These properties determine what a transfer of the instrument can even mean before any rail is chosen.", "source_refs": [ "SRC-004", "SRC-012", "SRC-017", "SRC-021" ], "questions": [ { "id": "instrument-bearer-or-registered", "text": "Is the instrument transferable in bearer form, or does transfer require registration, issuer involvement or operator participation?", "kind": "constraint", "answer_data": [ "Bearer or registered indicator", "Parties whose participation is required for transfer", "Legal basis for the transfer mechanism" ] }, { "id": "instrument-fungibility-grade", "text": "Are units of this instrument class fully fungible with each other, and what conditions break fungibility?", "kind": "classification", "answer_data": [ "Fungibility indicator", "Conditions that break fungibility such as series, taint or encumbrance", "Consequence for valuation and substitution" ] }, { "id": "instrument-divisibility-floor", "text": "What is the smallest transferable quantity of the instrument, and is it the same as the unit's minor unit?", "kind": "measurement", "answer_data": [ "Minimum transferable quantity", "Relationship to the denominating unit's minor unit", "Handling of sub-minimal residuals" ] }, { "id": "instrument-offline-capability", "text": "Can value in this instrument be transferred without connectivity to the issuer or ledger, and under what limits?", "kind": "requirement", "answer_data": [ "Offline transfer capability indicator", "Value or count limits applying offline", "Reconciliation obligation after reconnection" ] } ], "data_elements": [ { "id": "instrument-transfer-mode", "name": "instrumentTransferMode", "description": "How title to the instrument passes: bearer delivery, ledger entry, registered assignment or issuer-mediated transfer.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-017" ] }, { "id": "instrument-fungibility", "name": "instrumentFungibility", "description": "Whether units of the class are interchangeable and any conditions that break interchangeability.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-012" ] }, { "id": "instrument-minimum-transfer-quantity", "name": "instrumentMinimumTransferQuantity", "description": "Smallest quantity of the instrument that can be transferred, expressed in the denominating unit.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-021" ] } ], "artifacts": [], "inline_only_rationale": "Transferability is a set of coded properties on the instrument class specification artefact defined in the sibling finding; producing a second artefact would fragment one governed description of the same class." }, { "id": "cbdc-classes", "name": "Retail and wholesale CBDC classes", "description": "BIS FSI defines CBDCs as a direct liability of the central bank. Retail CBDC is intended for the general public; wholesale CBDC is for financial intermediaries and is like reserves with tokenisation features. Tokenisation is digital representation of a claim on a programmable platform. Architectures include one-tier, pure two-tier/intermediated and hybrid models. BIS legal analysis warns that rCBDC is not a perfect replica of cash because it is intangible, needs a technical system, and may have holding limits, programmability, interest or a contractual user relationship, so classifying it as cash, deposit or e-money imports the wrong legal regime unless lawmakers choose that result. Designation as currency and legal tender may strengthen its monetary-anchor function but is a legal choice. Payment execution on a CBDC platform remains WM-ECO-009; wallets remain WM-ECO-015.", "source_refs": [ "SRC-023", "SRC-024" ], "questions": [ { "id": "cbdc-classes-q01", "text": "Is this instrument retail CBDC, wholesale CBDC, tokenised commercial-bank money, or e-money, and is it a direct central-bank liability?", "kind": "classification", "answer_data": [ "cbdc_audience", "issuer_class", "token_or_account" ] }, { "id": "cbdc-classes-q02", "text": "Does this CBDC create a new instrument class or reuse cash, deposit or e-money legal rules, and which sibling owns wallets and payments?", "kind": "composition", "answer_data": [ "architecture_model", "legal_regime_choice", "payment_model_ref", "account_model_ref" ] }, { "id": "cbdc-classes-q03", "text": "Which holding caps, programmability, interest, identity and offline rules attach to the instrument class itself?", "kind": "constraint", "answer_data": [ "holding_cap", "programmable", "interest_bearing", "offline_capable" ] } ], "data_elements": [ { "id": "cbdc-classes-data01", "name": "cbdc_audience", "description": "Intended holders (retail, wholesale)", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023" ] }, { "id": "cbdc-classes-data02", "name": "architecture_model", "description": "Intermediation model (one-tier, two-tier, hybrid)", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023" ] }, { "id": "cbdc-classes-data03", "name": "token_or_account", "description": "Representation (token, account, hybrid)", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023" ] }, { "id": "cbdc-classes-data04", "name": "programmable", "description": "Conditional transfer support", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023", "SRC-024" ] }, { "id": "cbdc-classes-data05", "name": "interest_bearing", "description": "Whether the instrument itself pays interest", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] }, { "id": "cbdc-classes-data06", "name": "offline_capable", "description": "Offline transfer design", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] } ], "artifacts": [ { "id": "cbdc-classes-artifact01", "name": "BIS FSI CBDC taxonomy and architecture models", "description": "Retail/wholesale split, liability nature and architecture choices.", "media_or_form": [ "technical-report" ], "serial": false, "identity_strategy": "Identified by publisher, executive-summary title and publication date.", "source_refs": [ "SRC-023" ] } ], "inline_only_rationale": null } ] }, { "id": "issuer-and-claim", "name": "Issuer, Claim and Redeemability", "description": "Who stands behind the instrument, what the holder's claim actually is, what backs it, and on what terms it can be turned back into something else.", "source_refs": [ "SRC-006", "SRC-011", "SRC-016", "SRC-018" ], "findings": [ { "id": "issuer-identity-and-authority", "name": "Issuer identity and issuance authority", "description": "Every monetary instrument other than a purely decentralised token has an issuer that is a legal entity and that carries the resulting liability. The issuer is referenced by a governed global entity identifier, not by name. The authority to issue derives from a legal basis - treaty or statute for a central bank, an authorisation regime for an electronic money institution, or a crypto-asset authorisation for a token issuer - and that basis is itself evidence that must be recorded and can lapse.", "source_refs": [ "SRC-006", "SRC-009", "SRC-011", "SRC-012", "SRC-021" ], "questions": [ { "id": "issuer-governed-identifier", "text": "Which governed entity identifier designates the issuer, and which register was used to verify it?", "kind": "identity", "answer_data": [ "Legal entity identifier value", "Registration status and next renewal date", "Verification register reference and lookup timestamp" ] }, { "id": "issuance-legal-basis", "text": "On what legal basis does this entity have authority to issue the instrument, and in which jurisdictions does that basis hold?", "kind": "authority", "answer_data": [ "Legal instrument or authorisation reference", "Issuing jurisdiction references", "Validity period of the authority" ] }, { "id": "issuer-role-separation", "text": "Where issuance, distribution, custody and ledger operation are performed by different entities, which entity holds which role?", "kind": "ownership", "answer_data": [ "Role assignments with entity references", "Role definitions and their source", "Liability allocation between roles" ] }, { "id": "issuerless-instrument-handling", "text": "If the instrument has no identifiable issuer, how is the absence recorded and what downstream constraints follow?", "kind": "exception", "answer_data": [ "Issuerless indicator with justification", "Substitute accountability arrangement if any", "Constraints on treating the instrument as a claim" ] } ], "data_elements": [ { "id": "issuer-entity-ref", "name": "issuerEntityRef", "description": "Reference to the issuing legal entity by governed global entity identifier.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "issuance-authority-basis", "name": "issuanceAuthorityBasis", "description": "Citation of the legal instrument or authorisation that confers the power to issue, with its validity period.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] }, { "id": "issuer-role-assignment", "name": "issuerRoleAssignment", "description": "Mapping of issuance, distribution, custody and operation roles to referenced entities.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-016" ] } ], "artifacts": [ { "id": "issuer-authority-dossier", "name": "Issuer authority dossier", "description": "Evidence set binding the instrument class to its issuer: entity identifier verification result, authorisation or legal-basis citation, role allocation and the observation timestamps at which each was confirmed.", "media_or_form": [ "evidence bundle", "structured record", "document set" ], "serial": false, "identity_strategy": "Keyed by issuer entity identifier plus instrument class identifier; each verification adds an immutable observation entry rather than replacing the prior one.", "source_refs": [ "SRC-006", "SRC-011", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "claim-backing-and-redeemability", "name": "Claim, backing and redemption rights", "description": "What the holder actually owns differs sharply by form. Physical currency is a liability of the issuer at fixed nominal value. Electronic money is stored monetary value representing a claim on the issuer, issued on receipt of funds and redeemable on request. A stablecoin arrangement is expected to give a robust legal claim against the issuer or the reserve assets, redemption at par for single-currency arrangements, reserve assets that are unencumbered and readily convertible, and an effective stabilisation mechanism. Absence of a claim is itself a material, recordable fact.", "source_refs": [ "SRC-011", "SRC-016", "SRC-018", "SRC-005" ], "questions": [ { "id": "claim-against-whom", "text": "Against whom does the holder hold a legal claim, and is that claim against the issuer, the reserve assets, or neither?", "kind": "relationship", "answer_data": [ "Claim counterparty reference", "Claim type and enforceability basis", "Governing law and forum" ] }, { "id": "redemption-terms", "text": "On what terms can the instrument be redeemed - at what value, within what period, subject to what fees or minimum amounts?", "kind": "requirement", "answer_data": [ "Redemption value basis such as par or nominal", "Maximum redemption period", "Fees, minimums and conditions", "Legal or contractual source of the obligation" ] }, { "id": "backing-composition", "text": "What assets back the instrument, how are they segregated and safeguarded, and how frequently is their composition disclosed?", "kind": "evidence", "answer_data": [ "Reserve asset composition by class", "Segregation and custody arrangement", "Attestation or audit reference with its date", "Disclosure frequency" ] }, { "id": "stabilisation-failure-mode", "text": "What stabilisation mechanism maintains value, and what is the documented behaviour when it fails or redemption is suspended?", "kind": "exception", "answer_data": [ "Stabilisation mechanism description", "Suspension triggers and authority to suspend", "Historical de-pegging or suspension events with timestamps" ] } ], "data_elements": [ { "id": "claim-counterparty-ref", "name": "claimCounterpartyRef", "description": "Entity or asset pool against which the holder's legal claim runs, or an explicit assertion that no claim exists.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-016" ] }, { "id": "redemption-terms-object", "name": "redemptionTerms", "description": "Structured redemption terms: value basis, maximum period, fees, minimums and the legal source of the obligation.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-016" ] }, { "id": "reserve-composition", "name": "reserveComposition", "description": "Composition of backing assets by class with segregation and custody attributes, as at a stated observation time.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-005" ] }, { "id": "claim-absence-assertion", "name": "claimAbsenceAssertion", "description": "Explicit assertion, with justification, that the instrument confers no legal claim on any party.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-016" ] } ], "artifacts": [ { "id": "backing-and-redemption-attestation", "name": "Backing and redemption attestation", "description": "A dated third-party or issuer attestation of reserve composition, segregation and redemption capability, retained as the evidence basis for claim and backing assertions.", "media_or_form": [ "attestation document", "audit report", "structured disclosure" ], "serial": true, "identity_strategy": "Keyed by instrument class identifier plus attestation period; the serial sequence is the ordered attestation period ordinal, never a filename date.", "source_refs": [ "SRC-016", "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "id": "settlement-asset-character", "name": "Settlement-Asset Character", "description": "The instrument viewed as the asset used to discharge obligations: which class of settlement asset it is, and what it contributes to finality.", "source_refs": [ "SRC-004", "SRC-005", "SRC-020" ], "findings": [ { "id": "settlement-asset-classification", "name": "Settlement asset classification and risk profile", "description": "PFMI Principle 9 requires money settlements in central bank money where practical and available, and requires strict control of credit and liquidity risk where commercial bank money is used instead. Stablecoin guidance recognises a third case: settlement assets that are neither central bank nor commercial bank money and that carry additional financial risk. Classifying the instrument into one of these classes, with its credit and liquidity risk attributes, is a property of the instrument and is needed before any rail selection.", "source_refs": [ "SRC-004", "SRC-005" ], "questions": [ { "id": "settlement-asset-class-question", "text": "Is this instrument central bank money, commercial bank money, or a settlement asset that is neither?", "kind": "classification", "answer_data": [ "Settlement asset class code", "Basis for the classification", "Reference to the principle or guidance applied" ] }, { "id": "settlement-credit-liquidity-risk", "text": "What credit and liquidity risk does a holder or receiver bear when accepting this instrument in settlement?", "kind": "measurement", "answer_data": [ "Credit risk characterisation and counterparty", "Liquidity risk characterisation including convertibility to central bank money", "Risk-control measures documented by the issuer or arrangement" ] }, { "id": "settlement-asset-availability", "text": "To which categories of party is this settlement asset available, and is availability restricted to eligible institutions?", "kind": "access", "answer_data": [ "Eligible holder categories", "Eligibility criteria and authority setting them", "Wholesale versus retail availability indicator" ] }, { "id": "settlement-asset-substitution", "text": "If this settlement asset becomes unavailable, what substitute is designated and on what authority?", "kind": "exception", "answer_data": [ "Designated substitute asset reference", "Trigger conditions for substitution", "Authority that may declare substitution" ] } ], "data_elements": [ { "id": "settlement-asset-class", "name": "settlementAssetClass", "description": "Whether the instrument is central bank money, commercial bank money or another settlement asset.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "settlement-risk-profile", "name": "settlementRiskProfile", "description": "Structured characterisation of credit and liquidity risk borne by a receiver of the instrument in settlement.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "eligible-holder-categories", "name": "eligibleHolderCategories", "description": "Categories of party permitted to hold or receive the instrument as a settlement asset.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-021" ] } ], "artifacts": [], "inline_only_rationale": "Settlement asset classification is a coded assessment recorded on the instrument class specification and justified by the issuer authority dossier; the underlying PFMI assessments are produced and published by supervisory authorities under their own governance, so this model references them rather than generating an artefact." }, { "id": "finality-and-discharge-properties", "name": "Discharge and finality properties of the instrument", "description": "Two distinct properties are often conflated. Legal tender status confers, in principle, mandatory acceptance at full face value with power to discharge a payment obligation, subject to good-faith refusal, contractual agreement on other means, and anti-money-laundering limits. Settlement finality is the irrevocability and unconditionality of a transfer under an arrangement's rules and legal basis. This model records the instrument-side contribution: what the delivery of the instrument itself accomplishes in law. The transfer arrangement that confers finality is owned by the payment model.", "source_refs": [ "SRC-004", "SRC-014", "SRC-020" ], "questions": [ { "id": "discharge-effect", "text": "Does delivery of this instrument discharge a monetary obligation in a given jurisdiction, and on what legal basis?", "kind": "authority", "answer_data": [ "Discharge effect indicator per jurisdiction", "Legal basis citation", "Conditions or exceptions to discharge" ] }, { "id": "finality-legal-basis-dependency", "text": "Does finality for this instrument arise from the instrument itself or only from the rules and legal basis of a transfer arrangement?", "kind": "relationship", "answer_data": [ "Source of finality (instrument-intrinsic or arrangement-conferred)", "Referenced arrangement identifier where applicable", "Statement of what this model does not assert about the arrangement" ] }, { "id": "reversibility-window", "text": "After delivery of the instrument, under what circumstances can the transfer of value still be unwound?", "kind": "state", "answer_data": [ "Reversal grounds such as fraud, error or insolvency claw-back", "Time window and authority for reversal", "Jurisdictional variation" ] }, { "id": "acceptance-refusal-grounds", "text": "On what grounds may a creditor lawfully refuse this instrument despite its status?", "kind": "exception", "answer_data": [ "Refusal grounds and their legal source", "Quantitative acceptance limits such as coin count caps", "Contractual override provisions" ] } ], "data_elements": [ { "id": "discharge-effect-by-jurisdiction", "name": "dischargeEffectByJurisdiction", "description": "Per-jurisdiction assertion of whether tender of the instrument discharges a monetary obligation, with the legal basis and conditions.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-020" ] }, { "id": "finality-source", "name": "finalitySource", "description": "Whether finality is intrinsic to the instrument or conferred by an external transfer arrangement referenced by identifier.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "reversal-grounds", "name": "reversalGrounds", "description": "Enumerated grounds and windows under which a completed transfer of the instrument may still be unwound.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-020" ] } ], "artifacts": [ { "id": "discharge-status-assertion", "name": "Discharge status assertion", "description": "A dated, jurisdiction-scoped assertion of the instrument's discharge and acceptance effect, citing the legal instrument relied on and recording both the effective date of the law and the observation date of the assertion.", "media_or_form": [ "structured record", "legal citation set" ], "serial": false, "identity_strategy": "Keyed by instrument or unit identifier plus jurisdiction reference plus effective-from instant; assertions are appended, never edited in place.", "source_refs": [ "SRC-014", "SRC-020", "SRC-019" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "legal-status-and-jurisdiction", "name": "Legal Status and Jurisdiction", "description": "Where and on what terms the unit or instrument is lawful money, who is authorised to issue it, and what restrictions bound its holding and use.", "rationale": "Legal tender is conferred by specific legal instruments and is bounded rather than absolute; issuance is subject to authorisation regimes that can be granted, varied and withdrawn; and holding or usage limits are real constraints that change how an agent may reason about the instrument. None of this is derivable from the code list alone.", "source_refs": [ "SRC-011", "SRC-012", "SRC-014", "SRC-020", "SRC-021" ], "layers": [ { "id": "legal-tender-and-territory", "name": "Legal Tender and Territorial Validity", "description": "The jurisdictional footprint of the unit and instrument, and the acceptance obligations that attach within it.", "source_refs": [ "SRC-014", "SRC-020" ], "findings": [ { "id": "legal-tender-status", "name": "Legal tender status and its limits", "description": "Legal tender status is conferred by specific legal instruments and its effects are not defined uniformly. In the euro area, treaty provisions confer status on banknotes and a Council regulation on coins, while the concept itself is defined through recommendation and case law as mandatory acceptance at full face value with power to discharge. The same regulation caps obligatory acceptance at fifty coins in a single payment, proving that legal tender is quantitatively bounded. Status must therefore be asserted per jurisdiction, per instrument form, with its limits.", "source_refs": [ "SRC-014", "SRC-020" ], "questions": [ { "id": "legal-tender-assertion", "text": "In which jurisdictions does this instrument hold legal tender status, and which legal instrument confers it?", "kind": "authority", "answer_data": [ "Jurisdiction reference", "Conferring legal instrument citation", "Instrument forms covered such as notes or coin" ] }, { "id": "legal-tender-quantitative-limit", "text": "What quantitative limits bound the obligation to accept, such as caps on coin counts or cash payment thresholds?", "kind": "constraint", "answer_data": [ "Limit type and numeric threshold", "Legal source of the limit", "Parties exempt from the limit" ] }, { "id": "legal-tender-status-change", "text": "When did the current legal tender status take effect, and what status preceded it?", "kind": "temporal", "answer_data": [ "Effective-from timestamp with offset", "Prior status value", "Legal act that changed it" ] }, { "id": "non-tender-acceptance", "text": "For instruments without legal tender status, what governs acceptance and how is that recorded distinctly from tender status?", "kind": "definition", "answer_data": [ "Acceptance basis such as contract or scheme rule", "Explicit non-tender indicator", "Scope of parties bound by the acceptance basis" ] } ], "data_elements": [ { "id": "legal-tender-status-value", "name": "legalTenderStatus", "description": "Per-jurisdiction legal tender status of the unit or instrument form, with conferring instrument and effective period.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-020" ] }, { "id": "acceptance-limit", "name": "acceptanceLimit", "description": "Quantitative limit on the obligation to accept, such as a maximum number of coins or a cash payment ceiling.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-020" ] } ], "artifacts": [], "inline_only_rationale": "Legal tender assertions are recorded on the discharge status assertion artefact defined under the settlement-asset layer; duplicating them as a second artefact would create two governed statements of the same legal fact and invite divergence." }, { "id": "territorial-validity", "name": "Territorial validity and monetary sovereignty", "description": "A unit's jurisdictional footprint is not the same as its issuer's jurisdiction. A currency may be substituted for national units across a monetary union, adopted unilaterally by a jurisdiction that does not issue it, circulate alongside a domestic unit, or be lawful in dependent territories on different terms. This finding records the set of jurisdictions in which the unit functions as money and the basis on which it does so.", "source_refs": [ "SRC-002", "SRC-014", "SRC-001" ], "questions": [ { "id": "jurisdiction-footprint", "text": "Which jurisdictions and territories use this unit as money, and on what basis does each do so?", "kind": "spatial", "answer_data": [ "Jurisdiction references", "Basis code such as issuing jurisdiction, monetary union member, unilateral adoption or pegged parallel use", "Effective period per jurisdiction" ] }, { "id": "issuing-authority-territory", "text": "Which authority exercises monetary sovereignty over the unit, and is that authority distinct from the users of the unit?", "kind": "ownership", "answer_data": [ "Monetary authority entity reference", "Territory over which authority is exercised", "Territories using the unit outside that authority's control" ] }, { "id": "parallel-circulation", "text": "Does another monetary unit circulate in parallel in any of these territories, and how are the two related?", "kind": "relationship", "answer_data": [ "Parallel unit references", "Relation type such as peg, dual circulation or transitional coexistence", "Transitional end date where applicable" ] }, { "id": "accession-substitution-event", "text": "What accession, substitution or secession events changed the territorial footprint, and when did each take legal effect?", "kind": "event", "answer_data": [ "Event type", "Legal effect timestamp with offset", "Superseded unit reference", "Amendment or legal act reference" ] } ], "data_elements": [ { "id": "unit-jurisdiction-usage", "name": "unitJurisdictionUsage", "description": "Set of jurisdictions in which the unit functions as money, each with a usage basis and effective period.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-014" ] }, { "id": "monetary-authority-ref", "name": "monetaryAuthorityRef", "description": "Reference to the authority exercising monetary sovereignty over the unit.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-014" ] } ], "artifacts": [ { "id": "territorial-validity-map", "name": "Territorial validity map", "description": "A versioned mapping of monetary unit to jurisdictions with usage basis and effective periods, derived from code-list entity data and legal acts, used to answer whether a unit is lawful money in a given place at a given time.", "media_or_form": [ "structured dataset", "reference mapping" ], "serial": false, "identity_strategy": "Keyed by unit identifier plus jurisdiction reference plus effective-from instant; supersession is recorded by adding a new interval rather than mutating the prior one.", "source_refs": [ "SRC-001", "SRC-002", "SRC-014" ] } ], "inline_only_rationale": null } ] }, { "id": "authorisation-and-restrictions", "name": "Authorisation and Usage Restrictions", "description": "The supervisory permission behind the instrument and the restrictions that bound how it may be held, converted or used.", "source_refs": [ "SRC-011", "SRC-012", "SRC-016", "SRC-021" ], "findings": [ { "id": "issuer-authorisation-status", "name": "Issuer authorisation and supervisory status", "description": "Issuing electronic money or a token that references an official currency is a regulated activity in many jurisdictions, subject to authorisation, prudential requirements including own funds and safeguarding of received funds, and ongoing supervision. Authorisation is granted by a named competent authority, has a register entry, can be passported across a union, and can be varied, suspended or withdrawn. The current status is a time-bounded fact requiring its own observation timestamp.", "source_refs": [ "SRC-011", "SRC-012", "SRC-016" ], "questions": [ { "id": "authorisation-register-entry", "text": "Under which authorisation regime and register entry is the issuer permitted to issue this instrument?", "kind": "authority", "answer_data": [ "Regime citation", "Competent authority reference", "Register entry identifier and register URL", "Authorisation grant date" ] }, { "id": "authorisation-current-state", "text": "What is the current authorisation state, and when was that state last verified against the register?", "kind": "state", "answer_data": [ "Status value such as authorised, restricted, suspended or withdrawn", "Status effective timestamp", "Observation timestamp of the register check" ] }, { "id": "passporting-scope", "text": "Across which additional jurisdictions does the authorisation extend by passporting or recognition, and under what conditions?", "kind": "access", "answer_data": [ "Host jurisdiction references", "Recognition mechanism", "Conditions or carve-outs" ] }, { "id": "unauthorised-issuance-handling", "text": "How is an instrument recorded when its issuer is unauthorised, unregulated or outside any authorisation regime?", "kind": "exception", "answer_data": [ "Unregulated indicator with justification", "Known supervisory warnings or enforcement references", "Downstream handling constraints" ] } ], "data_elements": [ { "id": "authorisation-status", "name": "authorisationStatus", "description": "Current supervisory authorisation state of the issuer for this instrument, with effective and observation timestamps.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] }, { "id": "competent-authority-ref", "name": "competentAuthorityRef", "description": "Reference to the authority that granted and supervises the authorisation.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] }, { "id": "register-entry-ref", "name": "registerEntryRef", "description": "Locator of the public register entry evidencing the authorisation.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-016" ] } ], "artifacts": [ { "id": "authorisation-verification-record", "name": "Authorisation verification record", "description": "An append-only record of each check of the issuer's authorisation against a public register, capturing the register queried, the result, the status effective date and the observation instant.", "media_or_form": [ "verification log", "structured record" ], "serial": true, "identity_strategy": "Keyed by issuer entity identifier plus register reference; the serial sequence is a monotonically increasing verification ordinal independent of any date field.", "source_refs": [ "SRC-011", "SRC-012", "SRC-019" ] } ], "inline_only_rationale": null }, { "id": "usage-and-holding-restrictions", "name": "Holding, conversion and usage restrictions", "description": "Restrictions bound how much of an instrument may be held, whether it may be converted, and who may use it. Sources include design decisions such as holding limits contemplated for retail central bank digital currency, convertibility controls imposed by monetary authorities, prohibitions on interest-bearing use, and restrictive measures against specified parties. These are properties of the unit or instrument in a jurisdiction, not of any one account, and they must be time-bounded and jurisdiction-scoped.", "source_refs": [ "SRC-012", "SRC-016", "SRC-021", "SRC-020" ], "questions": [ { "id": "holding-limit-question", "text": "What limits apply to how much of this instrument a party may hold, and to which party categories do they apply?", "kind": "constraint", "answer_data": [ "Limit value and unit", "Party categories in scope", "Authority imposing the limit", "Effective period" ] }, { "id": "convertibility-restriction-question", "text": "Is conversion of this unit into other units restricted, and by what mechanism - controls, licensing, quotas or suspension?", "kind": "constraint", "answer_data": [ "Restriction type", "Restricted counter-units", "Licensing or exemption path", "Effective period" ] }, { "id": "restrictive-measure-linkage", "text": "Which restrictive-measure or sanctions regimes affect the unit, instrument or issuer, and where is the authoritative list held?", "kind": "security", "answer_data": [ "Regime reference", "Authoritative list locator", "Scope of the measure", "Observation timestamp of the check" ] }, { "id": "restriction-precedence", "text": "When restrictions from different authorities conflict, which prevails for a given party and transaction context?", "kind": "decision", "answer_data": [ "Competing restriction references", "Precedence rule and its legal basis", "Residual risk statement where no precedence exists" ] } ], "data_elements": [ { "id": "holding-limit-value", "name": "holdingLimit", "description": "Maximum permitted holding of the instrument for a party category in a jurisdiction, with effective period.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-021", "SRC-012" ] }, { "id": "convertibility-restriction-code", "name": "convertibilityRestriction", "description": "Coded restriction on converting the unit into other units, with scope and authority.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-016" ] }, { "id": "restrictive-measure-ref", "name": "restrictiveMeasureRef", "description": "Reference to an externally maintained restrictive-measure or sanctions regime affecting the unit, instrument or issuer.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [], "inline_only_rationale": "Restrictions are referenced by pointer to externally maintained authoritative lists that are versioned and republished by their owning authorities; copying them into a local artefact would create a stale shadow of a fast-moving legal source and is deliberately avoided." } ] } ] }, { "id": "lifecycle-and-succession", "name": "Lifecycle and Succession", "description": "How units and instrument series come into being, change identity, and cease - including the continuity rules that let historical records remain interpretable.", "rationale": "Amendment 180 moving Bulgaria from BGN to EUR, the withdrawal of the EUR 500 note from issuance, and the maintenance of a separate historic code list all demonstrate that units and instrument series have distinct, dated lifecycles whose transitions must be modelled explicitly rather than inferred from a current-state snapshot.", "source_refs": [ "SRC-001", "SRC-002", "SRC-009", "SRC-013", "SRC-014" ], "layers": [ { "id": "unit-lifecycle", "name": "Unit Lifecycle and Succession", "description": "States of a monetary unit over time and the mappings that link a retired unit to what replaced it.", "source_refs": [ "SRC-001", "SRC-002", "SRC-013", "SRC-014" ], "findings": [ { "id": "unit-lifecycle-states", "name": "Unit lifecycle states and effective dating", "description": "The governing registry maintains current codes separately from historic denominations, and each change is issued as a numbered amendment with an effective date. A unit therefore moves through states - announced, current, superseded, historic - and the model must record both the date the change takes legal or registry effect and the date the local record observed it, because these differ and downstream restatements depend on the distinction.", "source_refs": [ "SRC-001", "SRC-002", "SRC-019" ], "questions": [ { "id": "unit-current-state", "text": "What lifecycle state does this unit occupy, and which registry list is it currently carried on?", "kind": "state", "answer_data": [ "Lifecycle state value", "Registry list membership (current or historic)", "State effective timestamp with offset" ] }, { "id": "unit-amendment-provenance", "text": "Which numbered amendment introduced or retired this unit, and when was it issued versus when did it take effect?", "kind": "provenance", "answer_data": [ "Amendment number", "Amendment issue timestamp", "Effective timestamp", "Amendment document locator" ] }, { "id": "unit-observation-lag", "text": "When did the local record first observe this state, and what lag existed between the effective instant and the observation instant?", "kind": "temporal", "answer_data": [ "Observation timestamp with offset", "Computed lag duration", "Ingestion process reference" ] }, { "id": "unit-pre-announcement-handling", "text": "How is a unit handled between its announcement and its effective date, when both the old and new unit are valid for different purposes?", "kind": "lifecycle", "answer_data": [ "Pre-effective state marker", "Permitted uses during the transition window", "Dual-validity end timestamp" ] } ], "data_elements": [ { "id": "unit-lifecycle-state", "name": "unitLifecycleState", "description": "Current lifecycle state of the unit within its governing registry.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "unit-effective-time", "name": "unitEffectiveTime", "description": "Instant at which the current state took registry or legal effect, as an RFC 3339 timestamp with explicit offset.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-019" ] }, { "id": "unit-observed-time", "name": "unitObservedTime", "description": "Instant at which the local record observed or ingested the state, recorded separately from the effective instant.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-019" ] }, { "id": "unit-amendment-ref", "name": "unitAmendmentRef", "description": "Reference to the numbered registry amendment that produced the current state.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "unit-amendment-feed", "name": "Unit amendment feed", "description": "An ordered, append-only feed of registry amendments affecting monetary units, each carrying an amendment ordinal, issue instant, effective instant, affected unit codes and the source document locator.", "media_or_form": [ "change feed", "structured dataset", "document set" ], "serial": true, "identity_strategy": "Keyed by scheme reference plus amendment ordinal issued by the maintenance agency; the ordinal is the serial sequence and no date is used as the key.", "source_refs": [ "SRC-001", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "succession-and-redenomination", "name": "Succession, redenomination and continuity of contracts", "description": "When a unit is replaced, historical amounts must remain interpretable. Euro introduction supplies the normative pattern: continuity of legal instruments is preserved, conversion rates are fixed and irrevocable, expressed as one unit of the new currency in terms of the old with six significant figures, and inverse or derived rates must not be substituted. Redenomination without substitution - dropping zeros in a currency reform - raises the same restatement problem with a different mechanism.", "source_refs": [ "SRC-002", "SRC-013", "SRC-014" ], "questions": [ { "id": "successor-mapping", "text": "Which unit succeeds this one, and what is the fixed conversion factor and its direction of expression?", "kind": "relationship", "answer_data": [ "Successor unit reference", "Fixed conversion factor with its significant figures", "Direction of expression", "Legal act establishing the factor" ] }, { "id": "contract-continuity-rule", "text": "What rule preserves continuity of instruments and obligations expressed in the retired unit?", "kind": "requirement", "answer_data": [ "Continuity provision citation", "Scope of instruments covered", "Party rights to terminate or renegotiate, if any" ] }, { "id": "restatement-obligation", "text": "Must historical records be restated into the successor unit, or preserved in the original unit with the mapping applied at read time?", "kind": "decision", "answer_data": [ "Restatement policy", "Retention rule for original-unit values", "Audit trail requirement for restated values" ] }, { "id": "dual-period-events", "text": "During a changeover period, how are amounts, prices and obligations disambiguated between the retiring and successor units?", "kind": "lifecycle", "answer_data": [ "Changeover window start and end timestamps", "Mandatory unit qualification rules", "Dual-display or dual-pricing obligations" ] } ], "data_elements": [ { "id": "successor-unit-ref", "name": "successorUnitRef", "description": "Reference to the unit that replaces this one on withdrawal or substitution.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-014" ] }, { "id": "fixed-conversion-factor", "name": "fixedConversionFactor", "description": "Legally fixed and irrevocable conversion factor between the retiring and successor unit, retained at full published precision.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "continuity-provision-ref", "name": "continuityProvisionRef", "description": "Citation of the legal provision preserving continuity of instruments denominated in the retired unit.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-014" ] } ], "artifacts": [ { "id": "succession-mapping-table", "name": "Succession mapping table", "description": "A versioned table mapping retired units to successors with fixed conversion factors at full precision, the legal act establishing each factor, and the changeover window, used to restate or interpret historical amounts.", "media_or_form": [ "reference table", "structured dataset" ], "serial": false, "identity_strategy": "Keyed by retiring unit identifier plus successor unit identifier plus effective-from instant; entries are immutable once the effective instant has passed.", "source_refs": [ "SRC-013", "SRC-014", "SRC-002" ] } ], "inline_only_rationale": null } ] }, { "id": "instrument-stock-lifecycle", "name": "Instrument Series and Stock Lifecycle", "description": "Series and issue lifecycle of an instrument class, and the rules for withdrawal, demonetisation and exchange - at class level, never at holding level.", "source_refs": [ "SRC-009", "SRC-011", "SRC-016" ], "findings": [ { "id": "instrument-series-and-issue", "name": "Instrument series, denominations and issue", "description": "An instrument class is issued in series with defined denomination sets. Euro banknotes illustrate this: a first series of seven denominations and a second series in which one denomination was not continued. For token instruments the analogue is the deployed contract version and the ledger on which it is deployed, together with fork history. Series identity matters because acceptance, exchange and validation rules can differ by series.", "source_refs": [ "SRC-008", "SRC-009", "SRC-021" ], "questions": [ { "id": "series-denomination-set", "text": "Which series exist for this instrument class and what denomination set does each carry?", "kind": "composition", "answer_data": [ "Series identifier and name", "Denomination face values in the denominating unit", "Series introduction timestamp" ] }, { "id": "series-issuance-state", "text": "Is each series still being issued, and if issuance ceased, when and by whose decision?", "kind": "state", "answer_data": [ "Issuance state per series", "Cessation timestamp with offset", "Deciding authority and decision reference" ] }, { "id": "token-version-and-fork", "text": "For a ledger-based instrument, which contract or protocol version and ledger identify the current series, and what fork or migration history precedes it?", "kind": "provenance", "answer_data": [ "Digital ledger identifier", "Contract or protocol version reference", "Fork or migration events with effective timestamps" ] }, { "id": "series-validation-features", "text": "What series-specific authentication or validation features must a verifier check, and where is the specification published?", "kind": "validation", "answer_data": [ "Feature list per series", "Verification specification locator", "Feature deprecation timeline" ] } ], "data_elements": [ { "id": "instrument-series-id", "name": "instrumentSeriesIdentifier", "description": "Identifier of a series or issue generation of the instrument class.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-008" ] }, { "id": "instrument-denomination-set", "name": "instrumentDenominationSet", "description": "Face values issued within a series, expressed in the denominating unit.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "instrument-issuance-state", "name": "instrumentIssuanceState", "description": "Whether a series is currently issued, discontinued for issuance, or fully withdrawn.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "series-catalogue", "name": "Instrument series catalogue", "description": "A catalogue of series for an instrument class with denomination sets, issuance states, introduction and cessation instants, and references to the applicable authentication or contract specifications.", "media_or_form": [ "catalogue", "structured dataset", "specification reference set" ], "serial": true, "identity_strategy": "Keyed by instrument class identifier plus series identifier assigned by the issuer; the serial sequence is the issuer's series ordinal, not a publication date.", "source_refs": [ "SRC-008", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "withdrawal-and-exchange", "name": "Withdrawal, demonetisation and exchange guarantees", "description": "Ceasing to issue an instrument is distinct from removing its legal tender status, and both are distinct from ending the ability to exchange it. A denomination may stop being issued while remaining legal tender and exchangeable indefinitely at the issuing central banks. For electronic money and tokens, the corresponding event is termination of the issuance programme with a redemption obligation that survives it. Conflating these three transitions produces incorrect conclusions about whether value can still be realised.", "source_refs": [ "SRC-009", "SRC-011", "SRC-016" ], "questions": [ { "id": "issuance-cessation-vs-tender", "text": "Has issuance ceased, has legal tender status ended, or both - and on what dates did each occur separately?", "kind": "lifecycle", "answer_data": [ "Issuance cessation timestamp", "Legal tender cessation timestamp", "Deciding authority per transition" ] }, { "id": "exchange-window", "text": "Until when, where and by whom can the instrument still be exchanged for current money, and is the guarantee open-ended?", "kind": "temporal", "answer_data": [ "Exchange deadline or open-ended indicator", "Exchanging entities and locations", "Exchange value basis and any deductions" ] }, { "id": "post-termination-redemption", "text": "For a terminated electronic money or token programme, what redemption obligation survives and how is it funded?", "kind": "requirement", "answer_data": [ "Surviving redemption obligation citation", "Funding or reserve arrangement after termination", "Claim procedure and time limit" ] }, { "id": "unexchanged-value-treatment", "text": "What becomes of value never presented for exchange, and who acquires the benefit?", "kind": "retention", "answer_data": [ "Treatment of unpresented value", "Beneficiary and legal basis", "Record retention period for terminated series" ] } ], "data_elements": [ { "id": "issuance-cessation-time", "name": "issuanceCessationTime", "description": "Instant at which issuance of a series ceased, distinct from any legal tender change.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-019" ] }, { "id": "exchange-deadline", "name": "exchangeDeadline", "description": "Deadline until which the instrument may be exchanged, or an explicit open-ended marker.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "surviving-redemption-obligation", "name": "survivingRedemptionObligation", "description": "Redemption obligation that persists after an issuance programme is terminated, with its legal basis and claim procedure.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-016" ] } ], "artifacts": [], "inline_only_rationale": "Withdrawal and exchange facts are recorded as dated transitions on the instrument series catalogue artefact; issuing a separate artefact would split a single series timeline across two governed records and make the ordering of transitions ambiguous." } ] } ] }, { "id": "amount-and-conversion", "name": "Amount and Conversion", "description": "The monetary amount as a value object composed by every sibling model, and the arithmetic and rate-provenance rules that make amounts comparable and convertible without silent corruption.", "rationale": "Amounts are always a pair of a numeric value and a unit reference, are constrained in scale by the unit's minor unit and again by the target payload's data type, and conversion is governed by explicit legal rules in at least one major case: fixed rates at six significant figures, no rounding of the rate, no derived inverse rates and round-half-up on the result.", "source_refs": [ "SRC-001", "SRC-010", "SRC-013", "SRC-015" ], "layers": [ { "id": "money-amount-value-object", "name": "Monetary Amount Value Object", "description": "The structure, precision and arithmetic of a monetary amount, independent of what is being paid for.", "source_refs": [ "SRC-001", "SRC-013", "SRC-015" ], "findings": [ { "id": "money-amount-structure", "name": "Amount structure, scale and sign", "description": "A monetary amount is inseparably a numeric value plus a reference to the unit that denominates it; a bare number is not an amount. Financial messaging types bind the two together and impose their own total and fractional digit limits, which may be narrower than the unit's minor unit. Sign conventions, zero and the prohibition on binary floating point for exact decimal values are part of the value object's contract, not of any consuming model.", "source_refs": [ "SRC-001", "SRC-013", "SRC-015" ], "questions": [ { "id": "amount-unit-binding", "text": "How is the numeric value bound to its unit reference so that the pair cannot be separated in transit or storage?", "kind": "composition", "answer_data": [ "Value and unit reference pair structure", "Prohibition on bare numeric amounts", "Serialisation constraint per projection" ] }, { "id": "amount-permitted-scale", "text": "What scale is permitted for this amount, given the unit's minor unit and the narrower limits of the target payload type?", "kind": "constraint", "answer_data": [ "Unit minor unit", "Payload total and fraction digit limits", "Governing effective scale and its derivation" ] }, { "id": "amount-numeric-representation", "text": "What numeric representation preserves exactness, and what representations are prohibited?", "kind": "requirement", "answer_data": [ "Required decimal representation", "Prohibited representations such as binary floating point", "Overflow and precision-loss handling" ] }, { "id": "amount-sign-and-zero", "text": "What do a negative amount and a zero amount mean in this model, and where must direction be carried instead?", "kind": "definition", "answer_data": [ "Sign semantics", "Zero-amount semantics", "Statement that debit or credit direction belongs to the consuming model" ] } ], "data_elements": [ { "id": "amount-value", "name": "amountValue", "description": "Exact decimal numeric value of the monetary amount.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-015" ] }, { "id": "amount-unit-ref", "name": "amountUnitRef", "description": "Reference to the monetary unit denominating the amount; mandatory and inseparable from the value.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-015" ] }, { "id": "amount-scale", "name": "amountScale", "description": "Number of fractional digits carried by the amount, which must satisfy both the unit minor unit and the payload constraint.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-015" ] } ], "artifacts": [ { "id": "money-amount-schema", "name": "Monetary amount value-object schema", "description": "The format-neutral contract for a monetary amount - value, unit reference, scale and representation constraints - together with per-projection binding rules for messaging, document and database targets.", "media_or_form": [ "schema definition", "specification document" ], "serial": false, "identity_strategy": "Keyed by a stable value-object identifier within the adopting Dimension namespace, versioned semantically; projections reference the version, never a copy.", "source_refs": [ "SRC-001", "SRC-015" ] } ], "inline_only_rationale": null }, { "id": "rounding-and-arithmetic", "name": "Rounding, arithmetic and allocation rules", "description": "Conversion arithmetic is legally constrained in at least one authoritative case: the conversion rate must not itself be rounded or truncated, inverse rates derived from it must not be used, and a converted result landing exactly halfway is rounded up. Beyond conversion, allocation of a total across parts must not create or destroy value, which requires an explicit remainder rule. These rules belong to the amount, not to any consuming process, so that all consumers round identically.", "source_refs": [ "SRC-013", "SRC-001" ], "questions": [ { "id": "rounding-mode-rule", "text": "Which rounding mode applies to a converted or computed amount, and what is its normative source?", "kind": "requirement", "answer_data": [ "Rounding mode identifier", "Normative source citation", "Scope of application and any jurisdictional variation" ] }, { "id": "rate-precision-preservation", "text": "How is the full published precision of a rate preserved through the computation, and what intermediate rounding is prohibited?", "kind": "constraint", "answer_data": [ "Rate significant figures as published", "Prohibition on rounding or truncating the rate", "Prohibition on derived inverse rates", "Permitted intermediate precision" ] }, { "id": "allocation-remainder-rule", "text": "When a total is allocated across parts, what rule assigns the remainder so that the parts sum exactly to the total?", "kind": "process", "answer_data": [ "Allocation algorithm identifier", "Remainder assignment rule", "Determinism and reproducibility requirement" ] }, { "id": "rounding-divergence-evidence", "text": "How is a divergence between this model's rounding result and a counterparty's result detected, evidenced and resolved?", "kind": "evidence", "answer_data": [ "Comparison procedure", "Tolerance threshold", "Discrepancy record with both inputs and both results", "Escalation path" ] } ], "data_elements": [ { "id": "rounding-mode", "name": "roundingMode", "description": "Rounding mode applied to computed or converted amounts, with the normative source establishing it.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "rate-application-constraint", "name": "rateApplicationConstraint", "description": "Constraints on applying a rate: preserved precision, prohibition on inverse-rate derivation and on intermediate rounding.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "allocation-rule-ref", "name": "allocationRuleRef", "description": "Reference to the deterministic allocation algorithm used to distribute a total across parts without value leakage.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "arithmetic-rule-profile", "name": "Monetary arithmetic rule profile", "description": "A named, versioned profile fixing rounding mode, rate-application constraints and allocation rules for a jurisdiction or scheme, referenced by every consumer so results are reproducible across implementations.", "media_or_form": [ "rule profile", "specification document", "test fixture set" ], "serial": false, "identity_strategy": "Keyed by profile name plus semantic version within the adopting Dimension namespace; each profile cites the legal or scheme provision it encodes.", "source_refs": [ "SRC-013", "SRC-015" ] } ], "inline_only_rationale": null } ] }, { "id": "conversion-and-rate-reference", "name": "Conversion and Rate Reference", "description": "The definitional side of converting between units: the ordered pair, the rate type, and the provenance and fitness for use of any rate relied upon.", "source_refs": [ "SRC-010", "SRC-013" ], "findings": [ { "id": "conversion-rate-reference", "name": "Currency pair, rate type and rate provenance", "description": "A rate is meaningless without an ordered pair, a quotation convention, a rate type and a provenance record. Rate types differ fundamentally: a legally fixed conversion factor is irrevocable and directional, while a published reference rate is an observation computed at a stated time under a stated procedure and may carry an explicit caveat against use for transactions. Publication can also be suspended for a pair when representative rates cannot be established, so a rate reference must record availability as well as value.", "source_refs": [ "SRC-010", "SRC-013" ], "questions": [ { "id": "pair-and-convention", "text": "Which ordered pair does the rate express and in which direction is the quotation stated?", "kind": "definition", "answer_data": [ "Base unit reference", "Quote unit reference", "Quotation direction and units-per-unit convention" ] }, { "id": "rate-type-classification", "text": "Is this a legally fixed conversion factor, a published reference rate, a scheme rate or a transacted rate?", "kind": "classification", "answer_data": [ "Rate type code", "Establishing authority or publisher", "Irrevocability indicator" ] }, { "id": "rate-observation-time", "text": "At what instant was the rate determined and at what instant published, and in which time zone was each stated?", "kind": "temporal", "answer_data": [ "Determination timestamp with offset", "Publication timestamp with offset", "Originating time zone as published", "Ingestion timestamp" ] }, { "id": "rate-fitness-for-use", "text": "What does the publisher say the rate may and may not be used for, and what fallback applies when it is unavailable?", "kind": "quality", "answer_data": [ "Publisher usage caveat verbatim reference", "Permitted and prohibited uses", "Fallback rate source and trigger", "Suspension record for the pair where applicable" ] } ], "data_elements": [ { "id": "rate-base-unit-ref", "name": "rateBaseUnitRef", "description": "Reference to the base unit of the ordered currency pair.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-013" ] }, { "id": "rate-quote-unit-ref", "name": "rateQuoteUnitRef", "description": "Reference to the quote unit of the ordered currency pair.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-013" ] }, { "id": "rate-value", "name": "rateValue", "description": "Rate value retained at the full precision published by the source, without rounding or truncation.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "rate-type", "name": "rateType", "description": "Whether the rate is a fixed statutory conversion factor, a published reference rate, a scheme rate or a transacted rate.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-013" ] }, { "id": "rate-determination-time", "name": "rateDeterminationTime", "description": "Instant at which the rate was determined, distinct from publication and ingestion instants.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-019" ] }, { "id": "rate-usage-caveat", "name": "rateUsageCaveat", "description": "Publisher-stated limitation on the purposes for which the rate may be used.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "rate-reference-snapshot", "name": "Rate reference snapshot", "description": "An immutable snapshot of rates for a set of pairs as published by one source, carrying determination, publication and ingestion instants, the publisher's usage caveat, and an availability status per pair including suspension.", "media_or_form": [ "structured dataset", "snapshot record" ], "serial": true, "identity_strategy": "Keyed by publisher reference plus publication sequence ordinal; the determination instant is an attribute of the snapshot and is never used as its identifier.", "source_refs": [ "SRC-010", "SRC-019" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "governance-and-interoperability", "name": "Governance, Alignment and Assurance", "description": "How the local record stays faithful to its authoritative sources, how it maps to external schemes without over-claiming conformance, and how it is validated, published, retained and accessed.", "rationale": "Every substantive fact in this model is sourced from an externally governed registry, legal instrument or standard that versions independently. The model must therefore carry explicit provenance, alignment-not-conformance semantics, validation evidence and retention rules, or agents will silently consume stale or mis-mapped monetary reference data.", "source_refs": [ "SRC-001", "SRC-006", "SRC-015", "SRC-019" ], "layers": [ { "id": "authority-and-provenance", "name": "Authority, Provenance and Stewardship", "description": "Which body governs each fact, how changes are tracked, and who is accountable for the local record.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007" ], "findings": [ { "id": "authoritative-source-and-stewardship", "name": "Authoritative source, amendment tracking and record stewardship", "description": "Different facts in this model have different masters: the currency code and minor unit are governed by the ISO 4217 maintenance agency secretariat, digital token identifiers by the DTI registration authority, entity identifiers by the LEI issuer network, legal tender by legislators, and authorisation by competent authorities. The local record is a derived copy that must name its master per field, track that master's amendment stream, and name a steward accountable for the copy. The registry names the holder and settlement rail operator as maintainers; for the unit and instrument definitions themselves the accountable steward is the issuing or maintaining authority's designated counterpart in the adopting Dimension.", "source_refs": [ "SRC-001", "SRC-002", "SRC-006", "SRC-007" ], "questions": [ { "id": "master-source-per-field", "text": "For each governed field, which external body is the master and what is the locator of the source of record?", "kind": "provenance", "answer_data": [ "Field-to-master mapping", "Source locator per master", "Source version or amendment reference", "Retrieval timestamp" ] }, { "id": "amendment-subscription", "text": "How does the local record learn of amendments at each master, and what is the maximum acceptable staleness?", "kind": "process", "answer_data": [ "Change-detection mechanism per master", "Polling or notification cadence", "Maximum staleness threshold and breach action" ] }, { "id": "record-steward-accountability", "text": "Who is accountable for the correctness of this local record, and what decisions may they take without the master's involvement?", "kind": "ownership", "answer_data": [ "Steward role and entity reference", "Decision rights and their limits", "Escalation path to the master" ] }, { "id": "derived-versus-asserted", "text": "Which fields are copied from a master and which are locally asserted judgements, and how is the difference made visible to consumers?", "kind": "quality", "answer_data": [ "Derivation flag per field", "Basis for each local assertion", "Consumer-visible marking convention" ] } ], "data_elements": [ { "id": "source-of-record-ref", "name": "sourceOfRecordRef", "description": "Per-field reference to the external master, including its version or amendment reference and retrieval timestamp.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "record-steward-ref", "name": "recordStewardRef", "description": "Reference to the role or entity accountable for the local record's correctness.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "derivation-flag", "name": "derivationFlag", "description": "Marker distinguishing fields copied from a master from fields asserted locally.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "provenance-ledger", "name": "Provenance ledger", "description": "An append-only ledger recording, for each change to the local record, the master source, source version, retrieval instant, ingestion instant, the effecting agent or process and the resulting record version.", "media_or_form": [ "append-only log", "structured dataset" ], "serial": true, "identity_strategy": "Keyed by record identifier plus monotonically increasing change ordinal; entries are immutable and reference source amendment identifiers rather than dates.", "source_refs": [ "SRC-001", "SRC-002", "SRC-019" ] } ], "inline_only_rationale": null } ] }, { "id": "external-alignment", "name": "External Alignment and Payload Interoperability", "description": "Mapping to external code schemes and message formats as alignments, with conflicts recorded rather than smoothed over.", "source_refs": [ "SRC-003", "SRC-008", "SRC-015" ], "findings": [ { "id": "code-scheme-alignment", "name": "Code-scheme alignment and recorded conflicts", "description": "The same economic thing can be identified in several schemes at once - a token pegged to an official currency may carry a digital token identifier while also referencing an ISO 4217 code, and national schemes may use codes that clash with the international list. Alignment is a mapping with a stated equivalence strength, not a claim of conformance. Where schemes disagree - for example on whether a unit is money at all, or on effective dates for a substitution - the conflict is recorded and neither side is silently preferred.", "source_refs": [ "SRC-003", "SRC-008", "SRC-012" ], "questions": [ { "id": "scheme-mapping-strength", "text": "Which external scheme identifiers map to this unit or instrument, and what is the equivalence strength of each mapping?", "kind": "interoperability", "answer_data": [ "Target scheme reference and identifier value", "Equivalence strength such as exact, broader, narrower or related", "Mapping author and review timestamp" ] }, { "id": "conformance-claim-basis", "text": "What evidence supports any claim of conformance to an external standard, and where is only alignment claimed?", "kind": "evidence", "answer_data": [ "Conformance evidence reference such as certification or test results", "Explicit alignment-only marker where no evidence exists", "Standard clause coverage summary" ] }, { "id": "scheme-conflict-record", "text": "Where two schemes disagree about this unit or instrument, how is the conflict recorded and surfaced to consumers?", "kind": "exception", "answer_data": [ "Conflicting assertions with their scheme references", "Conflict category", "Resolution status and any interim guidance" ] }, { "id": "scheme-version-drift", "text": "How is drift handled when one scheme publishes a change that another has not yet reflected?", "kind": "temporal", "answer_data": [ "Per-scheme version and effective instants", "Drift duration", "Interim mapping behaviour" ] } ], "data_elements": [ { "id": "scheme-mapping", "name": "schemeMapping", "description": "Mapping entries linking this unit or instrument to identifiers in external schemes, each with equivalence strength and review metadata.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-008" ] }, { "id": "conformance-claim", "name": "conformanceClaim", "description": "Claim of conformance to an external standard with its supporting evidence reference, or an explicit alignment-only marker.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "scheme-conflict-entry", "name": "schemeConflictEntry", "description": "Recorded disagreement between two external schemes about the same unit or instrument, with resolution status.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-012" ] } ], "artifacts": [ { "id": "alignment-crosswalk", "name": "Alignment crosswalk", "description": "A versioned crosswalk between this model's unit and instrument records and external code schemes, carrying equivalence strength, evidence pointers, and an explicit conflict register.", "media_or_form": [ "crosswalk table", "structured dataset" ], "serial": false, "identity_strategy": "Keyed by local record identifier plus target scheme reference plus crosswalk version; each row cites the scheme version it was mapped against.", "source_refs": [ "SRC-003", "SRC-008", "SRC-015" ] } ], "inline_only_rationale": null }, { "id": "payload-interoperability", "name": "Payload and projection interoperability", "description": "Messaging standards bind amount and currency together in dedicated data types and externalise volatile code sets that are republished on their own cadence. Projecting this model into a payload therefore constrains scale, code-set membership and the permitted set of codes, and a projection that silently truncates or substitutes is a defect. Storage and interface choices - documents, message schemas, tool interfaces or database collections - are projections that must round-trip the semantics defined here.", "source_refs": [ "SRC-015", "SRC-001" ], "questions": [ { "id": "projection-binding-rules", "text": "For each target projection, what binding rules govern how a unit reference and an amount are rendered and parsed?", "kind": "interoperability", "answer_data": [ "Projection identifier", "Field bindings for value, unit and scale", "Round-trip test reference" ] }, { "id": "external-code-set-dependency", "text": "Which externalised code sets does a projection depend on, and how is their republication cadence tracked?", "kind": "composition", "answer_data": [ "Code set names and locators", "Published version and effective instant", "Update cadence and tracking mechanism" ] }, { "id": "projection-lossiness", "text": "What information defined in this model cannot be carried by a given projection, and how is that loss disclosed?", "kind": "constraint", "answer_data": [ "Unrepresentable elements per projection", "Disclosure mechanism to consumers", "Compensating out-of-band carriage where used" ] }, { "id": "unsupported-code-handling", "text": "How does a projection behave when it encounters a unit code that its bound code set does not contain?", "kind": "exception", "answer_data": [ "Rejection or quarantine behaviour", "Error signalling convention", "Remediation path and responsible role" ] } ], "data_elements": [ { "id": "projection-binding", "name": "projectionBinding", "description": "Binding rules mapping the model's elements onto a specific target projection, with round-trip test references.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "external-code-set-ref", "name": "externalCodeSetRef", "description": "Reference to an externalised code set a projection depends on, with its published version and effective instant.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "projection-loss-note", "name": "projectionLossNote", "description": "Disclosure of model elements that a given projection cannot represent.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] } ], "artifacts": [ { "id": "projection-binding-profile", "name": "Projection binding profile", "description": "Per-target binding profile with field mappings, code-set version pins, lossiness disclosure and executable round-trip fixtures proving semantic preservation.", "media_or_form": [ "binding profile", "schema definition", "test fixture set" ], "serial": false, "identity_strategy": "Keyed by projection target identifier plus profile semantic version; code-set dependencies are pinned by version reference rather than copied.", "source_refs": [ "SRC-015", "SRC-001" ] } ], "inline_only_rationale": null } ] }, { "id": "assurance-access-retention", "name": "Validation, Access and Retention", "description": "Proving the record is correct, controlling who may see which parts of it, and governing how long superseded states are kept.", "source_refs": [ "SRC-001", "SRC-006", "SRC-010", "SRC-019" ], "findings": [ { "id": "validation-and-evidence", "name": "Validation rules and supporting evidence", "description": "Monetary reference data admits strong mechanical checks: code format and check-character validation for identifiers that define one, cross-checking alphabetic against numeric codes, verifying minor unit against the authoritative list, confirming that an amount's scale satisfies both unit and payload constraints, and confirming that an entity identifier resolves in its register with an active status. Each check produces evidence with its own observation timestamp, distinct from the effective time of the fact checked.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007", "SRC-019" ], "questions": [ { "id": "validation-rule-set", "text": "Which validation rules apply to this record, and which are blocking versus advisory?", "kind": "validation", "answer_data": [ "Rule identifiers and definitions", "Severity classification", "Rule version and its source" ] }, { "id": "validation-evidence-record", "text": "What evidence is retained for each validation run, and how are effective time and observation time recorded separately?", "kind": "evidence", "answer_data": [ "Rule outcome per record", "Observation timestamp with offset", "Effective timestamp of the fact validated", "Validator identity and version" ] }, { "id": "validation-failure-disposition", "text": "What happens to a record that fails a blocking rule - is it quarantined, superseded, or published with a defect marker?", "kind": "process", "answer_data": [ "Disposition state", "Responsible role", "Remediation deadline and escalation" ] }, { "id": "stale-record-detection", "text": "How is a record detected as stale relative to its master, and what confidence signal is exposed to consumers?", "kind": "quality", "answer_data": [ "Staleness measure and threshold", "Last successful reconciliation instant", "Consumer-facing confidence indicator" ] } ], "data_elements": [ { "id": "validation-outcome", "name": "validationOutcome", "description": "Result of applying a validation rule to a record, with severity and validator identity.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "validation-observed-time", "name": "validationObservedTime", "description": "Instant at which a validation was performed, recorded separately from the effective time of the validated fact.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "record-confidence", "name": "recordConfidence", "description": "Consumer-facing confidence indicator derived from validation outcomes and staleness relative to the master.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-010" ] } ], "artifacts": [ { "id": "validation-report", "name": "Validation report", "description": "A per-run report of rule outcomes across the reference set, with validator version, observation instant, failure dispositions and staleness measures per master source.", "media_or_form": [ "report", "structured dataset" ], "serial": true, "identity_strategy": "Keyed by validation profile identifier plus run ordinal; the run ordinal is the serial sequence and the observation instant is an attribute, not the key.", "source_refs": [ "SRC-001", "SRC-019" ] } ], "inline_only_rationale": null }, { "id": "access-retention-publication", "name": "Access, retention and publication of monetary reference data", "description": "Most of this model is public reference data that authoritative bodies publish free of charge and permit free reuse, which argues for open read access. But not all of it is: authorisation checks, restrictive-measure linkages, reserve attestations and supplier-licensed rate feeds carry licence, confidentiality or redistribution constraints. Retention is asymmetric to deletion: superseded unit states and succession mappings must be kept indefinitely to keep historical amounts interpretable, while cached third-party feeds may be subject to contractual deletion.", "source_refs": [ "SRC-001", "SRC-007", "SRC-010", "SRC-016" ], "questions": [ { "id": "publication-and-licence", "text": "Which parts of the record may be published openly and under what licence or reuse terms from the upstream source?", "kind": "access", "answer_data": [ "Publishable field set", "Upstream licence or reuse statement", "Attribution requirement", "Redistribution restrictions" ] }, { "id": "restricted-attribute-scope", "text": "Which attributes are restricted, on what basis, and to which roles are they visible?", "kind": "privacy", "answer_data": [ "Restricted attribute list", "Restriction basis such as licence, confidentiality or supervisory sensitivity", "Permitted roles and purposes" ] }, { "id": "supersession-retention", "text": "How long are superseded unit states, succession mappings and rate snapshots retained, and what justifies indefinite retention?", "kind": "retention", "answer_data": [ "Retention period or indefinite marker per class", "Justification tied to historical interpretability", "Storage tier and immutability guarantee" ] }, { "id": "deletion-constraints", "text": "Under what circumstances may data be deleted, and what must survive deletion to preserve the audit chain?", "kind": "retention", "answer_data": [ "Deletion triggers such as licence expiry or contractual obligation", "Tombstone content that survives", "Approval role for deletion" ] }, { "id": "access-audit-trail", "text": "What access events are logged, and how long is the access log itself retained?", "kind": "security", "answer_data": [ "Logged event types", "Log fields including actor, scope and timestamp with offset", "Log retention period and immutability" ] } ], "data_elements": [ { "id": "publication-classification", "name": "publicationClassification", "description": "Classification of each field or record as openly publishable, attribution-required or restricted.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "upstream-licence-ref", "name": "upstreamLicenceRef", "description": "Reference to the upstream source's licence or reuse terms constraining republication.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-010" ] }, { "id": "retention-rule", "name": "retentionRule", "description": "Retention period or indefinite-retention marker per record class, with the justification and any deletion trigger.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-013", "SRC-016" ] } ], "artifacts": [ { "id": "publication-and-retention-policy", "name": "Publication and retention policy", "description": "The governed policy binding each record class to a publication classification, upstream licence constraint, retention rule and deletion trigger, with the approval role for exceptions.", "media_or_form": [ "policy document", "structured record" ], "serial": false, "identity_strategy": "Keyed by policy identifier plus semantic version within the adopting Dimension namespace; superseded versions are retained for audit.", "source_refs": [ "SRC-001", "SRC-007", "SRC-010", "SRC-016" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "resolve-monetary-unit", "name": "Resolve monetary unit reference", "description": "Resolve a code, identifier or scheme-qualified string to the governed monetary unit record valid at a stated instant, returning kind, minor unit, lifecycle state and successor where the unit is retired.", "inputs": [ "Code or identifier value", "Code scheme reference", "As-of instant as an RFC 3339 timestamp with offset" ], "outputs": [ "Resolved unit record with scheme identifiers", "Lifecycle state and validity interval", "Successor unit reference where the unit is retired", "Resolution confidence and source version used" ], "preconditions": [ "A code scheme reference is supplied or unambiguously inferable", "The local copy of the scheme is within its maximum staleness threshold" ], "effects": [ "Emits a resolution event carrying the source version and observation instant", "Records a miss when no unit matches, without inventing a placeholder" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-007" ] }, { "id": "validate-unit-identifier", "name": "Validate unit identifier and code consistency", "description": "Apply format, check-character and cross-field validation to a unit identifier, including consistency between alphabetic and numeric codes and between the declared minor unit and the authoritative list.", "inputs": [ "Candidate identifier and scheme reference", "Declared numeric code and minor unit where present", "Authoritative list version" ], "outputs": [ "Validation outcome per rule with severity", "Discrepancy detail where a cross-check fails", "Observation timestamp of the validation run" ], "preconditions": [ "The authoritative list version is retrievable and its retrieval instant is recorded" ], "effects": [ "Appends outcomes to the validation report", "Sets a blocking disposition when a mandatory rule fails" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-007" ] }, { "id": "classify-instrument", "name": "Classify monetary instrument form and settlement-asset class", "description": "Assign the instrument form, transfer mode, claim structure and settlement-asset class from documented issuer, backing and legal evidence, recording the criteria satisfied and those not evidenced.", "inputs": [ "Instrument class specification draft", "Issuer authority dossier", "Backing and redemption evidence" ], "outputs": [ "Instrument form code with satisfied criteria", "Settlement-asset class with risk characterisation", "List of unevidenced criteria flagged as gaps" ], "preconditions": [ "Issuer identity is resolved or explicitly asserted absent", "At least one primary legal or supervisory source is cited" ], "effects": [ "Updates the instrument class specification", "Opens a gap item for each unevidenced criterion rather than defaulting" ], "source_refs": [ "SRC-004", "SRC-005", "SRC-011", "SRC-017" ] }, { "id": "assert-legal-status", "name": "Assert legal tender and discharge status for a jurisdiction", "description": "Produce a jurisdiction-scoped, time-bounded assertion of legal tender status, discharge effect, acceptance limits and lawful refusal grounds, citing the legal instrument relied on.", "inputs": [ "Unit or instrument reference", "Jurisdiction reference", "As-of instant" ], "outputs": [ "Discharge status assertion with legal citations", "Quantitative acceptance limits", "Enumerated refusal grounds", "Effective and observation timestamps" ], "preconditions": [ "A primary legal instrument is identified for the jurisdiction", "Territorial validity has been established for the unit" ], "effects": [ "Appends a new assertion; prior assertions are never edited in place", "Flags jurisdictions where no primary source could be found as gaps" ], "source_refs": [ "SRC-014", "SRC-020" ] }, { "id": "derive-amount-scale", "name": "Derive and enforce permitted amount scale", "description": "Compute the effective permitted scale for an amount from the unit's minor unit and the narrower constraints of the target projection, and reject or flag amounts that violate it.", "inputs": [ "Unit reference", "Target projection identifier", "Candidate amount value" ], "outputs": [ "Effective permitted scale", "Conformance result for the candidate amount", "Divergence record where unit and projection constraints differ" ], "preconditions": [ "Denomination profile for the unit is resolved", "A projection binding profile exists for the target" ], "effects": [ "Blocks serialisation of a non-conforming amount", "Records the divergence for governance review" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-015" ] }, { "id": "convert-monetary-amount", "name": "Convert a monetary amount between units", "description": "Convert an amount using a referenced rate under the governing arithmetic rule profile, preserving full rate precision, refusing derived inverse rates and applying the prescribed rounding only to the final result.", "inputs": [ "Source amount with unit reference", "Target unit reference", "Rate reference including type and determination instant", "Arithmetic rule profile reference" ], "outputs": [ "Converted amount at the permitted scale", "Full computation trace including unrounded intermediate value", "Rate provenance and any publisher usage caveat" ], "preconditions": [ "The rate is directionally applicable and not derived by inversion", "The rate's fitness for the intended use is not excluded by its publisher", "Both units are resolvable at the stated as-of instant" ], "effects": [ "Emits a conversion record retaining inputs, rate and rounding decision", "Refuses conversion and raises an exception when only an excluded or unavailable rate exists" ], "source_refs": [ "SRC-010", "SRC-013" ] }, { "id": "apply-unit-succession", "name": "Apply unit succession to historical amounts", "description": "Map amounts expressed in a retired unit into its successor using the fixed conversion factor and continuity rules, preserving the original-unit value alongside the restated value.", "inputs": [ "Historical amount with retired unit reference", "Succession mapping table version", "Restatement policy" ], "outputs": [ "Restated amount in the successor unit", "Preserved original amount and unit", "Applied factor, legal act citation and restatement audit entry" ], "preconditions": [ "A succession mapping exists with a legally established factor", "The as-of instant of the amount falls before the changeover end" ], "effects": [ "Writes an audit entry linking original and restated values", "Leaves the original value immutable" ], "source_refs": [ "SRC-002", "SRC-013", "SRC-014" ] }, { "id": "verify-issuer-authorisation", "name": "Verify issuer identity and authorisation", "description": "Resolve the issuer's governed entity identifier against its register and check the authorisation state for the instrument, recording the observation instant and the status effective date separately.", "inputs": [ "Issuer entity identifier", "Authorisation regime reference", "Register locator" ], "outputs": [ "Entity resolution result with registration status", "Authorisation state with effective and observation timestamps", "Passporting scope where applicable" ], "preconditions": [ "The register is reachable and its response is attributable to a named authority" ], "effects": [ "Appends an authorisation verification record", "Downgrades record confidence when verification fails or cannot be completed" ], "source_refs": [ "SRC-006", "SRC-011", "SRC-012" ] }, { "id": "reconcile-with-master-registry", "name": "Reconcile local record against master registries", "description": "Compare the local reference set against each master registry's current publication and amendment stream, producing a differential and opening discrepancy items rather than auto-overwriting local assertions.", "inputs": [ "Local reference set version", "Master registry publication and amendment stream", "Reconciliation policy" ], "outputs": [ "Differential of added, changed and retired entries", "Discrepancy items with proposed dispositions", "Staleness measure per master" ], "preconditions": [ "Each master's source locator and version are recorded", "Field-level derivation flags distinguish copied from locally asserted values" ], "effects": [ "Updates the provenance ledger with source version and ingestion instant", "Never overwrites a locally asserted field without steward approval" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-015" ] }, { "id": "publish-reference-snapshot", "name": "Publish an immutable reference snapshot", "description": "Emit a versioned, immutable snapshot of the publishable reference set for a projection target, applying publication classification, licence attribution and lossiness disclosure.", "inputs": [ "Reference set version", "Projection binding profile", "Publication and retention policy" ], "outputs": [ "Immutable snapshot with content digest", "Attribution and licence notice", "Lossiness disclosure and code-set version pins" ], "preconditions": [ "All blocking validation rules pass or exceptions are approved", "Upstream licence terms permit the intended redistribution" ], "effects": [ "Registers the snapshot with an integrity digest", "Retains superseded snapshots per the retention rule" ], "source_refs": [ "SRC-001", "SRC-007", "SRC-015" ] } ], "composition": [ { "target": "WM-ECO-009 Payment / Funds Transfer", "relation": "REFERENCE", "purpose": "WM-ECO-009 references a unit or instrument to state what is being transferred; WM-ECO-004 supplies the settlement-asset class and discharge properties but never the instruction, rail, parties or settlement status.", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "target": "WM-ECO-015 Financial Account", "relation": "REFERENCE", "purpose": "An account declares its denomination and the instruments it may hold by referencing this model; account identity, scheme, status and holder relationships remain entirely in WM-ECO-015.", "required": false, "source_refs": [ "SRC-015", "SRC-017" ] }, { "target": "WM-ECO-017 Financial Position / Balance", "relation": "REFERENCE", "purpose": "A position quantifies an amount of a referenced unit or instrument as of a stated time; this model supplies the unit reference, scale and rounding contract, not the quantity or its owner.", "required": false, "source_refs": [ "SRC-001", "SRC-017" ] }, { "target": "Organization / legal entity model (issuer, maintenance agency, competent authority)", "relation": "REFERENCE", "purpose": "Issuers, registration authorities and supervisors are referenced by governed entity identifier so that corporate identity and hierarchy are maintained once, in the organization model.", "required": true, "source_refs": [ "SRC-006" ] }, { "target": "Jurisdiction / place model", "relation": "REFERENCE", "purpose": "Legal tender assertions, territorial validity and restriction scopes reference jurisdiction entities rather than embedding place definitions, because a unit can be lawful money outside its issuing jurisdiction.", "required": true, "source_refs": [ "SRC-014", "SRC-020" ] }, { "target": "Credit and debt claim model (legacy F8 successor)", "relation": "REFERENCE", "purpose": "Credit claims are denominated in units defined here and discharged by instruments defined here; the claim, principal and interest structure stays outside this model to keep the money-versus-claim boundary intact.", "required": false, "source_refs": [ "SRC-017", "SRC-018" ] }, { "target": "Sibling models that carry monetary amounts (charges, fares, valuations, cash flows)", "relation": "COMPOSE", "purpose": "The monetary amount value object with its unit binding, scale and arithmetic rule profile is defined once here and composed into any model that needs to express a sum of money.", "required": false, "source_refs": [ "SRC-013", "SRC-015" ] }, { "target": "Market price and reference-data time-series model", "relation": "REFERENCE", "purpose": "Continuous price discovery and tradable quote history are referenced, not owned; this model keeps only the pair definition, rate type and the provenance and fitness-for-use of a rate actually relied upon.", "required": false, "source_refs": [ "SRC-010" ] }, { "target": "ISO 4217 Codes for the representation of currencies (maintained by the ISO 4217 Maintenance Agency Secretariat)", "relation": "ALIGN", "purpose": "Alphabetic code, numeric code, minor unit and entity are aligned to the externally governed scheme by reference and version; no conformance is claimed without test evidence.", "required": true, "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] }, { "target": "ISO 24165 Digital token identifier (registration authority: DTI Foundation)", "relation": "ALIGN", "purpose": "Digital token units and the ledgers they depend on are aligned to DTI and digital ledger identifiers, giving a governed identifier for token money that ISO 4217 does not cover.", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "target": "ISO 20022 Universal financial industry message scheme", "relation": "ALIGN", "purpose": "Amount and currency representation, externalised code sets and business-concept naming are aligned for payload interoperability; the model remains syntax-independent and treats message schemas as projections.", "required": false, "source_refs": [ "SRC-015" ] }, { "target": "ISO 17442 Legal Entity Identifier", "relation": "ALIGN", "purpose": "Issuer, maintenance agency and competent authority references are aligned to the governed global entity identifier with its public reference data.", "required": false, "source_refs": [ "SRC-006" ] }, { "target": "CPMI-IOSCO Principles for financial market infrastructures, Principles 8 and 9", "relation": "ALIGN", "purpose": "Settlement-asset classification and the separation of instrument-side discharge properties from arrangement-side finality follow these principles; the model asserts alignment of vocabulary, not compliance of any infrastructure.", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "target": "Electronic money and crypto-asset legal frameworks (Directive 2009/110/EC; Regulation (EU) 2023/1114)", "relation": "ALIGN", "purpose": "Claim, issuance-on-receipt-of-funds, redeemability at par and the electronic money token versus asset-referenced token split are aligned to these instruments; the alignment is region-specific and marked as such.", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] }, { "target": "RFC 3339 Date and Time on the Internet: Timestamps", "relation": "ALIGN", "purpose": "All effective, observation, ingestion, determination and publication instants are expressed in the RFC 3339 profile with mandatory seconds and an explicit offset or Z.", "required": true, "source_refs": [ "SRC-019" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must nominate a named steward for the monetary reference record and a distinct steward for each master-source integration, with documented decision rights over locally asserted fields.", "The Dimension must pin, for every master source, the source locator, the consumed version or amendment ordinal and the maximum acceptable staleness, and must expose the current staleness to consumers.", "The Dimension must publish an arithmetic rule profile naming the rounding mode, rate-application constraints and allocation rule in force, with executable fixtures so that independent implementations produce identical results.", "The Dimension must record, per record class, a publication classification and a retention rule, and must retain superseded unit states and succession mappings for as long as any historical amount denominated in the retired unit remains interpretable.", "The Dimension must record upstream licence and attribution obligations before republishing any reference dataset derived from a maintenance agency or registration authority." ], "namespace_guidance": "Use a stable reverse-scoped namespace for this model's concepts, for example the Dimension root followed by an economy segment and a money segment, with distinct sub-namespaces for unit, instrument, amount and rate concepts. External scheme identifiers are never minted into the local namespace: they are carried as scheme-qualified references so that a currency code, a digital token identifier and an entity identifier remain attributable to their issuing authority. Local surrogate identifiers, when required, live in a clearly separated surrogate sub-namespace so consumers can tell a governed identifier from a locally assigned one.", "registry_links": [ "vr.wm-eco-004 is the registry entry for this model; WM-ECO-009, WM-ECO-015 and WM-ECO-017 hold inbound REFERENCE relations to it and must not restate unit or instrument semantics.", "External registries linked by reference: the ISO 4217 currency code service operated by the Maintenance Agency Secretariat, the ISO 24165 Digital Token Identifier registry operated by the DTI Foundation, and the Global LEI Index operated by GLEIF.", "The ISO 20022 repository is linked as the projection vocabulary for amount and currency representation and for externalised code sets consumed by payload bindings." ] }, "canon_and_patch": { "canonicalization_rules": [ "Canonical form is a unit-or-instrument record plus its typed attributes; rendered strings, symbols and locale formatting are excluded from the canonical form and are never parsed back into values.", "All instants in the canonical form are RFC 3339 with mandatory seconds and an explicit offset or Z; local time without an offset is rejected at ingestion.", "Numeric values are canonicalised as exact decimals with an explicit scale; binary floating point is prohibited in the canonical form and rates are stored at the full precision published by the source without rounding or truncation.", "Collection members are ordered deterministically by their governed identifier so that two canonical serialisations of the same state are byte-identical for digest purposes.", "External identifiers are canonicalised as a scheme reference plus a value, never as a bare string, so that an alphabetic code reused across eras cannot be silently conflated." ], "patch_rules": [ "Changes are expressed as additive, dated assertions with an effective instant and a separate observation instant; superseding a fact never mutates the superseded record in place.", "A patch that changes a field derived from a master source must cite the master's amendment ordinal or version; a patch to a locally asserted field must cite the steward and the basis of the assertion.", "Patches that would alter the meaning of a historical amount - minor unit, fixed conversion factor, succession mapping - require steward approval and an entry in the provenance ledger before publication.", "Retraction is modelled as a superseding assertion with a retraction reason, not as deletion; hard deletion is reserved for licence-driven or contractual removal and always leaves a tombstone." ], "compatibility_rules": [ "Adding an optional attribute, a new unit kind value or a new alignment mapping is backward compatible and increments the minor version.", "Narrowing a permitted scale, removing an attribute, changing a rounding mode or changing the meaning of an existing code value is breaking and increments the major version, with a migration note naming the affected record classes.", "Projection binding profiles pin the external code-set version they were built against; an upstream code-set republication that adds values is compatible, while a removal or redefinition requires a new binding profile version.", "Consumers must tolerate unknown optional attributes and must fail loudly rather than substitute defaults on an unrecognised unit code or an unrecognised rounding mode." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier assigned by the governing body of record - the ISO 4217 alphabetic code with its numeric code for currencies, funds and precious metals; the ISO 24165 Digital Token Identifier for digital token units; the ISO 17442 Legal Entity Identifier for issuers and authorities - always qualified by its scheme and the scheme version under which it is asserted.", "Governed global identifier or IRI published by a recognised registry or namespace authority where no master-system identifier of record exists, carried by scheme reference rather than copied into the local namespace.", "UUID or ULID assigned by the adopting Dimension, used only when neither of the above exists, held in a clearly separated surrogate namespace and never presented to consumers as authoritative.", "A date, an effective period, a publication instant or any derived date string is never an identifier; dates are attributes that qualify an identifier's validity interval." ], "timestamp_rule": "All time values are recorded in the RFC 3339 profile with mandatory seconds and an explicit offset or Z; local time without an offset is rejected. Event time and observation or ingestion time are recorded as separate fields whenever they can differ: for a unit change, the amendment effective instant is the event time and the instant the local record ingested it is the observation time; for a rate, the determination instant and the publication instant are event times while the ingestion instant is the observation time; for an authorisation check, the status effective instant is the event time and the register-query instant is the observation time. Where the source states a time zone such as a market close convention, the originating zone is retained alongside the offset-normalised value.", "serial_naming_rule": "Serial artefacts are named by a stable subject key plus a monotonically increasing ordinal issued by the authority that sequences them - the maintenance agency's amendment number for the unit amendment feed, the issuer's series ordinal for the series catalogue, the publisher's publication sequence for rate snapshots, and a locally issued run ordinal for validation reports and verification records. Ordinals are zero-padded to a fixed width for lexical ordering. A date or timestamp is never used as the serial component or as part of the artefact name; the effective and observation instants are attributes inside the artefact.", "integrity_rule": "Every published artefact carries a content digest computed over its canonical form, the identifier and version of the profile used to canonicalise it, and the set of master source versions it was derived from. Snapshots and append-only ledgers are immutable once published: corrections are issued as a new ordinal that references the corrected predecessor. A consumer that cannot verify the digest, or that finds a source-version pin outside the declared staleness threshold, must treat the artefact as unverified rather than as current." }, "policies": [ "Alignment is not conformance: an external standard may be cited as aligned by reference and version, but a conformance claim is published only where certification, test results or an authority's determination is attached as evidence.", "Public reference data is published openly where the upstream source permits free reuse, with required attribution preserved; licence-restricted feeds, supervisory-sensitive assessments and reserve attestations are never republished under an open classification.", "Locally asserted judgements - settlement-asset class, monetary character, boundary determinations - are marked as such and are never presented to consumers as if issued by the master registry.", "No monetary amount may be created, stored or transmitted without an accompanying unit reference; systems that cannot carry the pair must be treated as lossy projections and disclosed as such.", "Where two authoritative sources conflict, both assertions are retained with their authorities and the conflict is recorded openly; no silent precedence is applied without a documented and cited precedence rule." ], "crud": { "read": [ "Resolve a unit or instrument as of a stated instant, returning lifecycle state, successor and the source version used.", "Retrieve the denomination profile and effective permitted scale for a unit against a named projection target.", "Retrieve legal tender and discharge assertions for a unit or instrument in a jurisdiction at a stated instant, with their legal citations.", "Retrieve a rate reference snapshot with its determination, publication and ingestion instants and the publisher's usage caveat.", "Retrieve the alignment crosswalk and conflict register for a record against a named external scheme version." ], "create": [ "Register a new monetary unit record on receipt of a master-registry amendment, capturing amendment ordinal, effective instant and ingestion instant.", "Register a new instrument class specification with issuer reference, form classification and the evidence supporting each classification criterion.", "Append a discharge status assertion for a jurisdiction with its legal citation and both effective and observation instants.", "Append a rate reference snapshot from a named publisher with an availability status per pair, including suspension.", "Open a discrepancy item when reconciliation detects divergence between a local record and its master." ], "update": [ "Supersede a unit lifecycle state by appending a new dated assertion; the prior state remains readable and is never edited in place.", "Revise a locally asserted classification only with steward approval, recording the prior value, the new basis and the approving role.", "Re-pin a projection binding profile to a newer external code-set version, incrementing the profile version and re-running round-trip fixtures.", "Downgrade record confidence automatically when staleness exceeds the declared threshold or when an authorisation verification fails." ], "delete": [ "Hard deletion is prohibited for unit lifecycle states, succession mappings, fixed conversion factors and provenance ledger entries, because historical amounts cease to be interpretable without them.", "Cached licence-restricted third-party content may be deleted on licence expiry or contractual demand, leaving a tombstone recording what was removed, on whose instruction and when.", "Erroneously created records are retracted by a superseding assertion carrying a retraction reason, not removed from the ledger.", "Any deletion requires approval by the record steward and produces an immutable audit entry that itself is not deletable." ] }, "roles": [ { "name": "Monetary reference steward", "responsibilities": [ "Own the correctness of the local unit and instrument records and approve changes to locally asserted fields.", "Adjudicate conflicts between master sources and publish the precedence rule applied, with its basis.", "Approve retractions, deletions and retention exceptions." ] }, { "name": "Master-source integration operator", "responsibilities": [ "Track each master registry's publication and amendment stream and keep the consumed version pin and staleness measure current.", "Run reconciliation, open discrepancy items and record source version and ingestion instant in the provenance ledger.", "Escalate unreachable or changed source endpoints before the staleness threshold is breached." ] }, { "name": "Arithmetic and projection custodian", "responsibilities": [ "Maintain the arithmetic rule profile and its executable fixtures so conversion and rounding are reproducible across implementations.", "Maintain projection binding profiles, code-set version pins and lossiness disclosures, and run round-trip tests before publication.", "Block serialisation paths that cannot carry a unit reference alongside an amount." ] }, { "name": "Legal and regulatory analyst", "responsibilities": [ "Produce jurisdiction-scoped legal tender, discharge, authorisation and restriction assertions with primary legal citations.", "Re-verify authorisation status against public registers on the declared cadence and record effective and observation instants separately.", "Flag jurisdictions where no primary source could be found as explicit gaps rather than defaulting a status." ] }, { "name": "Publication and access controller", "responsibilities": [ "Apply publication classification and upstream licence terms before any dataset leaves the Dimension.", "Operate access controls and the access audit trail across bundle, layer, finding and artefact scopes.", "Approve and time-bound exceptions that widen default access." ] } ], "access": { "default_rule": "Default read access is open for records classified as publishable public reference data - unit identity, kind, denomination structure, naming, lifecycle state and succession mappings - reflecting that the governing registries publish these free of charge. Everything else, including authorisation verification records, restrictive-measure linkages, reserve attestations and licence-restricted rate feeds, is deny-by-default and released only to roles with a recorded purpose. Write access in every scope is deny-by-default and limited to the steward and the operator role designated for that scope.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Licence-restricted upstream feeds may be read by an integration operator for reconciliation but may not be republished, even in aggregate, where the licence prohibits redistribution.", "Supervisory-sensitive assessments and issuer authorisation verification detail may be released to a named counterparty under a time-bounded, purpose-recorded grant approved by the publication and access controller.", "During a changeover window, pre-effective unit records may be readable by integration and testing roles before their public effective instant, marked as pre-effective and excluded from public snapshots.", "Emergency read access to restricted attributes may be granted during an incident, limited to the incident window and reviewed afterwards, with every access logged." ], "audit_requirements": [ "Every read of a restricted attribute and every write in any scope is logged with actor identity, scope, record identifier, purpose and an RFC 3339 timestamp with explicit offset.", "Access logs are immutable and retained for at least the retention period of the records they describe; the log retention rule is itself published in the publication and retention policy.", "Every exception grant records the approving role, the justification, the scope and the expiry instant, and is reviewed on expiry.", "Reconciliation, validation and publication runs record the master source versions consumed and the resulting artefact digests so that any published figure can be traced to its inputs." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model identifier and registry entry", "Master source registry list with version pins and staleness thresholds", "Arithmetic rule profile identifier and version", "Publication classification and licence attribution summary", "Steward and operator role contacts" ], "read_order": [ "AGENTS.md at the record root, to obtain Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before any other access.", "The Specification URL, to load scope, boundaries and the bundle-layer-finding structure so the agent knows what this model does and does not own.", "The Storage type URL, to learn how the format-neutral semantics are projected into the concrete store, including identifier and timestamp conventions.", "The Interface URL, to discover read and write operations, their authorisation scopes and error conventions.", "The Processes URL, to learn reconciliation, validation, conversion and publication procedures and their preconditions.", "The master source registry list and arithmetic rule profile, to pin the external versions and rounding behaviour before performing any resolution or conversion." ] } }, "coverage": { "claim": "Base is Claude's 6-bundle / 14-layer / 26-finding structure for WM-ECO-004, plus two grok findings (SDR as unit and reserve asset, and retail/wholesale CBDC classes), giving 28 findings and 10 functions. It covers the monetary unit of account, the monetary instrument class, legal status and territorial validity, unit and series lifecycle, the monetary amount value object, and governance, alignment and assurance, for the sources actually consulted. E-money, MiCA, euro conversion arithmetic and legal-tender doctrine in the base are EU-derived and remain jurisdiction-scoped assertions. The FATF virtual-asset node and its admission function are deferred because they contradict the base classification of currency-referencing tokens; issuer-level stock and all holder positions remain outside this model. No claim of universal or exhaustive coverage of monetary law, token regimes, national cash-threshold schedules or banknote series catalogues is made.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Identifier priority runs master-system identifier (ISO 4217 code, DTI, LEI) before governed global identifier before locally assigned UUID or ULID, with dates excluded as identifiers. Code reuse across eras is handled by requiring scheme plus validity interval rather than a bare code." }, { "dimension": "lifecycle", "status": "covered", "notes": "Unit states with amendment-driven effective dating, succession and redenomination with fixed conversion factors, and the three separate instrument transitions - cessation of issuance, loss of legal tender and end of exchange - are modelled distinctly. Evidence includes amendment 180 and the discontinued EUR 500 issuance." }, { "dimension": "relationships", "status": "covered", "notes": "Instrument-to-unit denomination, issuer-to-instrument, unit-to-jurisdiction, unit-to-successor and rate-to-ordered-pair are all modelled. Inbound references from WM-ECO-009, WM-ECO-015 and WM-ECO-017 are declared in composition and their owned content is explicitly excluded." }, { "dimension": "temporal", "status": "covered", "notes": "RFC 3339 with mandatory seconds and explicit offset throughout; event time and observation or ingestion time are separated for amendments, rates and authorisation checks, and originating time zones such as a publication hour convention are retained alongside offset-normalised values." }, { "dimension": "provenance", "status": "covered", "notes": "Per-field master source with version or amendment ordinal, retrieval and ingestion instants, derivation flags separating copied from locally asserted fields, and an append-only provenance ledger keyed by change ordinal." }, { "dimension": "ownership", "status": "covered", "notes": "Issuer identity by governed entity identifier with role separation across issuance, distribution, custody and operation; local record stewardship assigned to a named steward with bounded decision rights and an escalation path to the master." }, { "dimension": "validation", "status": "covered", "notes": "Format and check-character validation, alphabetic-to-numeric cross-checks, minor unit verification against the authoritative list, scale conformance against both unit and payload constraints, and register resolution for entity identifiers, each producing dated evidence." }, { "dimension": "access", "status": "covered", "notes": "Open default for publishable reference data reflecting free-of-charge upstream publication, deny-by-default for authorisation, restriction, attestation and licence-restricted content, with scopes at bundle, layer, finding and artefact and time-bounded exceptions." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Indefinite retention mandated for unit lifecycle states, succession mappings and fixed conversion factors because historical amounts become uninterpretable without them; deletion confined to licence-driven removal with tombstones, and retraction expressed as superseding assertions." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignment-not-conformance to ISO 4217, ISO 24165, ISO 20022, ISO 17442 and CPMI-IOSCO vocabulary, with an explicit conflict register, projection binding profiles that pin external code-set versions, and disclosed lossiness per projection." }, { "dimension": "classification", "status": "covered", "notes": "Unit kind, instrument form, settlement-asset class and regulatory token subclass are separate coded axes rather than one flattened type, with unevidenced criteria opened as gaps instead of defaulted." }, { "dimension": "measurement and arithmetic", "status": "covered", "notes": "Amount and unit are inseparable; scale derives from minor unit narrowed by payload limits; rounding mode, full rate precision, prohibition on derived inverse rates and deterministic allocation are fixed in a versioned arithmetic rule profile with executable fixtures." }, { "dimension": "authority and legal status", "status": "covered", "notes": "Legal tender, discharge effect, acceptance limits, lawful refusal grounds, issuance legal basis and supervisory authorisation are asserted per jurisdiction with primary citations and separate effective and observation instants." }, { "dimension": "spatial", "status": "covered", "notes": "Territorial validity is modelled as unit-to-jurisdiction usage with a basis code covering issuing jurisdiction, union membership, unilateral adoption and parallel circulation, referencing an external jurisdiction model rather than defining places." }, { "dimension": "security and restriction", "status": "covered", "notes": "Restrictive-measure linkage is by pointer to externally maintained authoritative lists with observation timestamps; holding and convertibility limits are jurisdiction-scoped and time-bounded; access logging is immutable." }, { "dimension": "exception handling", "status": "covered", "notes": "Issuerless instruments, unauthorised issuers, special-purpose codes, unsupported codes in a projection, suspended rate pairs, conflicting classifications and conflicting restrictions each have an explicit handling question and disposition." }, { "dimension": "monetary aggregates and policy", "status": "not-applicable", "notes": "Money supply aggregates, monetary policy operations and macroeconomic statistics are compiled from holdings and flows owned by other models; this model defines only the referenced unit and instrument and would distort the boundary if it carried aggregates." }, { "dimension": "valuation and impairment", "status": "not-applicable", "notes": "Fair value measurement, impairment and expected credit loss on monetary claims are accounting outcomes applied to positions in WM-ECO-017 and to credit claims; only the amount value object and conversion arithmetic are needed here." }, { "dimension": "tax treatment", "status": "gap", "notes": "Tax characterisation of monetary instruments, particularly of token units, varies sharply by jurisdiction and no single primary source was identified that generalises. No structural node was created; this is recorded as a gap rather than presented as canonical." }, { "dimension": "physical security features", "status": "gap", "notes": "Authentication features of banknotes and coins are referenced only as a series-level specification pointer. Detailed feature taxonomies are issuer-specific and partly non-public, so no canonical structure is asserted." } ], "known_omissions": [ "Non-decimal and historical subdivision structures are acknowledged as a question but not modelled with a general algebra; only the decimal minor unit exponent is structurally supported, which is a real limitation for pre-decimalisation and some traditional units.", "Commodity money, barter units, mutual credit systems and local exchange units are not covered; the sources relied on address currencies, deposits, electronic money, CBDC and tokens, and extending to informal units without primary support would be unfounded.", "Negative interest, demurrage and other unit-level value-decay mechanisms are not modelled; they were judged to sit on positions and accounts rather than on the unit or instrument definition, but this boundary is unverified against a primary source.", "Islamic finance and other faith-based constraints on monetary instruments are not represented; no primary standards source was consulted and asserting structure would be speculative.", "Cross-border correspondent arrangements, nostro and vostro relationships and liquidity bridging are excluded as payment and account concerns, so a consumer needing to reason about the reachability of an instrument must combine this model with WM-ECO-009 and WM-ECO-015.", "Detailed reserve-asset quality criteria and stress thresholds for stablecoin arrangements are referenced at the level of principle only; supervisory technical standards implementing them were not consulted in full.", "National cash-payment ceilings, coin legal-tender limits and AML cash-reporting thresholds are jurisdictional schedules not reproduced here.", "Complete banknote and coin series catalogues of every issuing authority are not included; only the series-lifecycle pattern is.", "ISO/CD 24982 Digital currencies — Vocabulary is under development in ISO/TC 68 and is not yet a stable primary vocabulary.", "SNA 2025 updates to financial-instrument classes were not independently verified in this pass.", "Complementary, community and local currencies without ISO 4217 codes are representable as unlisted units but lack a global registry.", "Tokenised deposits, wholesale settlement tokens and multi-CBDC arrangements have design literature but few binding statutes.", "Islamic/near-money instruments and some mobile-money national laws are not exhaustively surveyed.", "Physical cash logistics, vault operations and note fitness sorting are operational and out of scope.", "Market FX, PPP and real-effective-rate statistics are omitted by design." ], "conflicts": [ "ISO 4217 carries fund codes and precious-metal codes in the same scheme as currencies while statistical classification places monetary gold and special drawing rights in a category separate from currency and deposits. This model resolves the tension by keeping a single identifier scheme reference but a separate monetary-character flag, and records that the two frameworks disagree about what belongs together.", "Legal tender is described as entailing mandatory acceptance at full face value with power to discharge, yet the same body of law caps obligatory acceptance of coins in a single payment and permits refusal in good faith or by contract. The model therefore treats legal tender as a bounded, conditional status rather than an absolute one, and records the limits alongside the status.", "Published reference rates carry an explicit caveat discouraging their use for transaction purposes, while many systems in practice use exactly those rates to convert transactional amounts. The model records the publisher's caveat verbatim as a fitness-for-use attribute and does not endorse the common practice.", "A token pegged to an official currency may be identified simultaneously by a digital token identifier and by reference to an ISO 4217 code, and different jurisdictions may classify the same token as electronic money, an asset-referenced instrument or an unregulated crypto-asset. Both classifications are retained with their authorities and no silent precedence is applied.", "Whether the instrument-side property of discharging an obligation and the arrangement-side property of settlement finality should be separated is a modelling judgement drawn from reading PFMI Principles 8 and 9 together with legal tender doctrine; a reader could reasonably place both entirely in the payment model, and this boundary is flagged for migration review.", "ISO 4217 defines currency as a medium of exchange identified by the location of the monetary authority (a coded unit). IMF/SNA define currency as notes and coins (an instrument form). Records must name which sense is used.", "FATF excludes digital fiat from virtual assets, while some jurisdictions have granted legal-tender status to Bitcoin or similar assets that fail IMF currency tests and are absent from ISO 4217. That is legal tender without catalogue membership.", "BIS notes that legal-tender acceptance is mandatory in some jurisdictions and merely a default discharge in others; no global default should be inferred.", "IMF classifies electronic money as deposits, not currency; some legal CBDC debates analogise rCBDC to cash. Classification as cash, deposit or a new class changes the imported legal regime.", "Previous F2 bundled payments, accounts, balances and exchange-rate quotes into this model; those now conflict with WM-ECO-009, WM-ECO-015, WM-ECO-017 and a price/quote sibling and must not be re-imported." ], "regional_assumptions": [ "Electronic money definition, issuance-at-par and redeemability obligations, and the electronic money token versus asset-referenced token split are drawn from European Union instruments and are region-specific. Other jurisdictions define stored-value and token instruments differently, and the model marks these as jurisdiction-scoped assertions rather than universal definitions.", "The conversion arithmetic rules relied upon - six significant figures, no rounding of the rate, no derived inverse rates and round-half-up on the result - come from the euro introduction framework. They are treated here as an exemplary, well-evidenced profile rather than as globally binding; other jurisdictions and schemes may mandate different rounding.", "Legal tender examples, the coin acceptance cap and the notion that legal tender is defined through recommendation and case law rather than statute are euro-area specific and must not be generalised.", "The reference-rate provenance pattern, including a daily concertation procedure, a stated publication hour in a European time zone and suspension of a pair, reflects one central bank's practice; other publishers use different determination times, conventions and availability rules.", "The identification of a maintenance agency secretariat and a registration authority as single authoritative points assumes continuity of the current custodianship arrangements for ISO 4217 and ISO 24165; a change of custodian would require re-pinning the master sources.", "EU e-money definition and par-redemption rules are primary for EEA electronic money and are an alignment, not a global statute.", "Euro changeover mechanics (fixed conversion rate, dual circulation, dual price display) are illustrated by the 2026 Bulgaria ISO 4217 amendment and do not automatically apply to other unions.", "SDR holder eligibility is limited to IMF members, the IMF and prescribed official holders; private SDR denomination in contracts does not create private SDR money.", "Dollarized and currency-board economies may use a foreign ISO unit as the domestic medium of exchange without issuing that unit.", "Common-law nemo dat exceptions for currency are described by BIS as typical, not universal." ], "adversarial_checks": [ "Attempted to justify keeping accounts, balances, payments and settlement rails in this model as the previous F2 version did. Rejected: the registry's own relation records assign account identity to WM-ECO-015, position quantification to WM-ECO-017 and transfer to WM-ECO-009, and PFMI separates the settlement asset (Principle 9) from the arrangement's finality (Principle 8), so only the asset-side property survives here.", "Tested whether an ISO 4217 alphabetic code alone is a sufficient identifier. Rejected: codes are retired to a historic list and the same three letters can denote different units in different eras, so the identifier must carry a scheme reference and a validity interval. This is why succession mapping and lifecycle states were made structural rather than optional.", "Tested whether the minor unit is always two decimal places. Rejected: the authoritative lists include units with zero and three decimal places and entries where no minor unit applies at all, notably precious metals and fund codes, so scale must be derived per unit and narrowed again by the target payload rather than assumed.", "Tested whether legal tender can be modelled as a single boolean on the unit. Rejected: status is conferred by different instruments for notes and for coins, is bounded by a coin-count cap and by good-faith and contractual refusal, and varies by jurisdiction and time, so it is modelled as a set of dated, jurisdiction-scoped assertions with limits.", "Tested whether all money can be reduced to a claim on an issuer. Rejected: some settlement assets are neither central bank nor commercial bank money and some token instruments confer no legal claim at all, so absence of a claim is modelled as an explicit assertion rather than as a missing value.", "Tested whether exchange rates should live in this model at all. Partially rejected: only the pair definition, rate type, precision and provenance are retained, because the publisher of a widely used reference rate explicitly discourages its use for transactions, which shows that definitional rate reference and transactional price discovery are different concerns belonging to different models.", "Tested whether ceasing to issue an instrument implies it is no longer money. Rejected: a discontinued banknote denomination can remain legal tender and exchangeable, so cessation of issuance, loss of legal tender and end of exchange are modelled as three separate dated transitions.", "Tested whether alignment to ISO 20022 or ISO 4217 could be stated as conformance. Rejected: no certification or test evidence was obtained, so all external standards are recorded as alignments by reference and version, and a conformance claim requires attached evidence.", "Payment-message fields, rails, finality and purpose codes were excluded so this model cannot substitute for WM-ECO-009.", "Named accounts, wallets, IBAN/scheme identifiers and holder balances were excluded so deposit instrument classes cannot substitute for WM-ECO-015 or WM-ECO-017.", "Market FX quotes were excluded despite appearing in the previous F2 exchangeRates layer; only official conversion factors and SDR basket amounts remain.", "Bitcoin and other virtual assets are not auto-classified as money or as ISO currencies; unofficial legal tender is a flagged conflict.", "CBDC is modelled as an instrument class with unresolved legal-regime choice (cash versus deposit versus new class), not as settled cash-equivalence." ] }, "researchAdjudication": { "boundaryDecision": { "entry_kind": "entity", "status": "accepted", "rationale": "Both providers independently returned entry_kind 'entity' and both scope WM-ECO-004 to the referenced thing money is, not to the acts done with it. Claude's boundary is the more complete of the two: nine in-scope and nine out-of-scope statements and eight named neighbour distinctions (WM-ECO-009 payment, WM-ECO-015 account, WM-ECO-017 position, credit claim, market data, organization, jurisdiction, securities), each with source refs, and it uses PFMI Principle 8 versus Principle 9 to place finality with the transfer arrangement and settlement-asset character with the instrument. The aggregate root is therefore the unit-plus-instrument definitional entity with the monetary amount as its owned value object; accounts, balances, payment execution and credit claims stay outside. No split or reclassification is warranted at adjudication time, since splitting unit from instrument would require a registry change that is not this decision's to make." }, "decisions": [ { "concept": "Base provider selection", "disposition": "Claude selected as base", "rationale": "Not chosen on size. Claude states nine in-scope and nine out-of-scope items and eight sourced neighbour distinctions, and uses PFMI Principles 8 and 9 to draw a defensible instrument-versus-arrangement line. Grok's scope statement pulls issuer-level outstanding stock quantification inside the model, which blurs the WM-ECO-017 edge that both providers otherwise agree on." }, { "concept": "Monetary amount value object ownership", "disposition": "Retained in base (amount-and-conversion bundle)", "rationale": "Grok treats the quantity-plus-unit amount as a composable value object belonging to siblings; the base owns it with scale, sign, exactness, rounding, allocation remainder and rate-provenance rules evidenced from ISO 20022 types and the euro conversion regulation. Placing these rules with the unit is what makes every consumer round identically, so the base's stronger reading is kept." }, { "concept": "SDR as unit of account and reserve asset", "disposition": "Accepted into unit-identity-and-codes", "rationale": "Materially absent from the base beyond a bare enumeration value; basket composition, eligible-holder classes and the absence of a claim on the IMF are separately evidenced and are class-level properties of the unit, not holder positions." }, { "concept": "Retail and wholesale CBDC classes", "disposition": "Accepted into instrument-classification", "rationale": "Adds the retail/wholesale split, tokenisation and architecture distinctions, and the BIS legal-regime-import warning, none of which the base carries. Sibling references inside the node match the base's boundary notes exactly." }, { "concept": "FATF virtual-asset boundary", "disposition": "Deferred with its admission function", "rationale": "The node is useful as an exclusion test, but verbatim acceptance would contradict the base's unit-kind-classification: the base permits currency-referencing tokens as digital token units, while this node classifies them as instrument classes denominated in a listed unit. The synthesizer cannot reconcile that conflict by editing. Both the finding and separate-virtual-asset function therefore remain deferred until the registry-level token boundary is resolved." }, { "concept": "SNA and broad-money classification of instrument types", "disposition": "Rejected", "rationale": "The node asserts broad-money inclusion as a property recorded here, which directly contradicts the base's out-of-scope statement excluding money supply aggregates and national accounts compilation and its not-applicable checklist entry for monetary aggregates. A verbatim copy would place two contradictory statements in one model. The AF1/AF2 crosswalk alone is deferred as an alignment-only mapping." }, { "concept": "Issuance, redemption and outstanding stock", "disposition": "Rejected", "rationale": "Its measurement question asks what quantity remains outstanding as issuer liability after an event. That is as-of quantification, which the chosen boundary assigns outside this model; accepting it would reopen the account/position edge that both providers otherwise close. Issuance and redemption terms themselves are already carried by claim-backing-and-redeemability and withdrawal-and-exchange." }, { "concept": "Electronic money as an instrument class", "disposition": "Rejected as duplicative", "rationale": "Stored value, claim on the issuer, issuance on receipt of funds and redeemability are already asserted across instrument-form-taxonomy and claim-backing-and-redeemability, and the limited-network exclusion is covered by the existing instrument-form-boundary-test question. Only the interest prohibition and closed/open circulation are incremental, which does not justify a second finding in the same layer." }, { "concept": "Money, currency and legal tender trichotomy", "disposition": "Rejected as duplicative", "rationale": "legal-tender-status and finality-and-discharge-properties already separate discharge effect, per-jurisdiction conferral, quantitative limits and lawful refusal, and code-scheme-alignment already records that an ISO listing is not a legal-tender determination. The node restates these with different framing." }, { "concept": "Tender limits, holding caps and title privileges", "disposition": "Rejected as duplicative", "rationale": "Coin caps and cash thresholds sit in legal-tender-status; holding caps, convertibility controls and restrictive measures sit in usage-and-holding-restrictions. Adding it would create two governed statements of the same jurisdictional limits and invite divergence." }, { "concept": "Public versus private money and issuer liability", "disposition": "Rejected as duplicative", "rationale": "The public/private distinction is the settlement-asset classification the base already carries as central bank money, commercial bank money or neither, and issuer identity by governed entity identifier with role separation is already in issuer-identity-and-authority." }, { "concept": "Redenomination, replacement and dual circulation", "disposition": "Rejected as duplicative", "rationale": "succession-and-redenomination already covers successor mapping, fixed and irrevocable conversion factors, contract continuity and changeover-period disambiguation, and unit-lifecycle-states covers movement to the historic list with amendment provenance." }, { "concept": "Series identity and demonetization", "disposition": "Rejected as duplicative", "rationale": "instrument-series-and-issue and withdrawal-and-exchange already separate cessation of issuance, loss of legal tender and end of exchange as three dated transitions. Only the commemorative and intrinsic-value coin exclusion is incremental and is better handled as a criterion under the existing boundary-test question." }, { "concept": "Par transfer, bearer status and nemo dat privilege", "disposition": "Deferred", "rationale": "The good-faith transferee privilege is a genuine legal property the base lacks, but the surrounding node restates bearer-versus-registered transfer, par convertibility and third-party usability that instrument-transferability and instrument-form-taxonomy already assert. Since the synthesizer copies verbatim and cannot merge, this belongs as an enrichment of the existing finding, not as a second transferability node." }, { "concept": "align-external-scheme function", "disposition": "Rejected", "rationale": "Its return contract includes the SNA class that was rejected above, and its remaining behaviour is covered by resolve-monetary-unit, reconcile-with-master-registry and the code-scheme-alignment finding. Accepting it would import a dependency on a node not in the model." }, { "concept": "Duplicate unit-resolution, scaling, redenomination, form-classification and legal-status functions", "disposition": "Rejected as duplicative", "rationale": "resolve-listed-unit, scale-minor-unit, map-redenomination, classify-instrument-form and determine-legal-status each map one-to-one onto an existing base function with equal or narrower behaviour, so no capability is gained." } ], "publicationHolds": [ "Source-reference remapping is mandatory before any copy is executed: the two providers use colliding SRC identifiers for different documents (including grok SRC-003 for the BIS FSI CBDC summary while claude SRC-003 is ISO 4217:2015, and grok SRC-009 for the IMF SDR factsheet while claude SRC-009 is ECB banknotes). A verbatim copy of either accepted finding would otherwise mis-cite its evidence.", "Source and live-version verification is not complete: every accepted source URL must be re-fetched and version-pinned, and the ISO 4217 amendment position must be reconciled, since the base cites amendment 180 effective 2026-01-01 while the other provider cites a Bulgaria euro-changeover amendment effective the same date without confirming they are the same instrument.", "Multi-profile validation is outstanding. The base's e-money definition, MiCA token split, euro conversion arithmetic (six significant figures, no derived inverse rates, round half up) and legal-tender doctrine are EU-derived. The model must be exercised against at least one non-EU and one non-euro-area profile before publication, and every such assertion must remain explicitly jurisdiction-scoped.", "The accepted CBDC and SDR nodes rest on sources not previously in the base register (BIS FSI CBDC summary, BIS 2024 legal analysis and IMF SDR factsheet). Each needs the same tier and primary-source assessment applied to the base's own twenty-one sources before it is promoted beyond reviewable draft.", "The published coverage claim must state that no universal or exhaustive coverage of monetary law, token regimes, national cash-threshold schedules or banknote series catalogues is asserted, and must carry the base's known omissions (non-decimal subdivisions, commodity and mutual-credit units, demurrage, faith-based constraints) alongside it." ], "deferredResearch": [ "Resolve whether a currency-referencing token is a monetary unit identified by DTI (base position, which lists digital token units as a unit kind with electronic-money-token and asset-referenced-token subclasses) or an instrument class denominated in an already-listed unit (grok position). Requires reading ISO 24165-2:2025 data elements against the MiCA definitions, and the outcome decides where token nodes attach.", "Reconcile the deferred FATF virtual-asset exclusion with the base's alternative treatment of carrying non-money codes as unit-of-account references marked non-monetary. Both cannot be the default disposition for the same object; pick one and state it in the scope statement before the FATF node or its admission function can be accepted.", "Decide whether issuer-level outstanding stock (currency in circulation as an issuer liability) belongs to WM-ECO-004 or to WM-ECO-017. Grok asserts it here as an issuance-stock measurement distinct from a holder balance; the base excludes all quantification. This needs an explicit registry-level ruling rather than a per-model judgement.", "Evaluate an alignment-only 2008 SNA AF1/AF2 crosswalk for code-scheme-alignment, carrying the instrument-class mapping but explicitly not broad-money inclusion, so the statistical alignment can be gained without breaching the aggregates exclusion.", "Enrich the existing instrument-transferability finding with the good-faith transferee protection and nemo dat exception evidenced by the BIS legal analysis, including whether that privilege extends to account-based claims, rather than adding a second transferability node.", "Verify the base's unverified assertion that negative interest, demurrage and other unit-level value-decay mechanisms sit on positions and accounts rather than on the unit or instrument definition; the base itself flags this boundary as lacking a primary source.", "Track ISO/CD 24982 Digital currencies vocabulary in ISO/TC 68 and re-open the digital instrument nodes once it stabilises, since neither provider could rely on it as a primary vocabulary in this pass." ] }, "statistics": { "sources": 29, "bundles": 6, "layers": 14, "findings": 28, "questions": 111, "artifacts": 21, "functions": 10 } }