# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-29T19:17:51Z", "synthesisSha256": "2a3770a4265be8754c719ee92452f1e9b8f2e7eca7a3a18853f7094f8607f22d", "providerMode": "single-provider-waiver", "providers": [ "Claude" ], "waivedProviders": [ "Grok" ] }, "metaModel": { "id": "WM-ECO-015", "registryId": "vr.wm-eco-015", "name": "Financial Account", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "entity", "family": "World Models", "category": "Society, people and institutions", "industry": [ "Cross-industry" ], "domain": [ "SOC.ECO.ACC" ], "tags": [ "financial", "account", "soc.eco.acc" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-eco-015-financial-account/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-eco-015", "model": { "registry_id": "vr.wm-eco-015", "model_id": "WM-ECO-015", "name": "Financial Account", "entry_kind": "entity", "purpose": "Give an agent the context needed to identify a financial account, know who holds and services it, what it is denominated in, what state it is in, what rules and protections bind it, and which contained or neighbouring models own everything else.", "scope_statement": "A financial account is an identified, durable container maintained by a financial institution or ledger operator for a business arrangement with one or more holders. This model owns account identity, identifier schemes, classification, party role bindings, servicing arrangement, denomination reference, bound terms and limits, protection designation, state and lifecycle, position declaration, provenance, evidence linkage, retention designation and interoperability projections. It owns no posting semantics, no monetary-unit semantics, no party master data, no payment execution and no runtime authorisation, enforcement or audit-trail semantics.", "in_scope": [ "Account identity and the identifier schemes that denote it (IBAN, domestic BBAN, sort code plus account number, masked PAN, proprietary and interface resource identifiers)", "Aliases, proxies, nicknames and display labels bound to the account", "Product, regulatory and tax classification, each carried with its scheme and scheme version", "Holder set, ownership structure (single, joint, trust, entity) and declared ownership shares", "Beneficial owner and controlling-person role bindings expressed as references to party identifiers", "Account servicer or provider and the servicing relationship", "Operating authority: mandates, authorised signatories, powers of attorney and delegated operating rights", "Denomination reference and permitted monetary instrument set, carried only as a reference", "Terms bound to the account: fees, interest, limits, facilities, notice periods and withdrawal restrictions", "Protection and guarantee designation (deposit guarantee scheme or deposit insurance ownership category)", "Account status, state transitions, restrictions, opening, closure, switching and dormancy determination", "Declared balances and statement designation as observations with an explicit as-of instant", "Provenance, supporting-evidence linkage, validation controls, retention designation, access designation and standards crosswalks" ], "out_of_scope": [ "Definition of currency, monetary units, minor units or instrument semantics (owned by WM-ECO-004)", "Creation, amendment, reversal, matching or interpretation of postings and derivation of balances from them (owned by WM-ECO-016)", "Party and legal-entity master data, entity verification and ownership hierarchies (referenced by identifier only)", "Payment instruction, clearing, settlement and funds-availability execution", "Issuance, evaluation, revocation or enforcement of data-access consents and the audit-trail record model", "Product catalogue definition and price-list governance independent of a specific account", "Deposit guarantee payout calculation and scheme operation", "Custody of escheated balances and reclaim-fund repayment obligations", "AML transaction monitoring, alerting, sanctions screening execution and case management", "Credit decisioning, risk scoring and capital treatment", "Card or payment instrument issuance and lifecycle", "Chart-of-accounts taxonomy governance and accounting policy", "Statement rendering channels, delivery infrastructure and notification transport" ], "boundary_notes": [ { "neighbor": "WM-ECO-004 monetary unit or instrument", "distinction": "The account declares its denomination and permitted instrument set as a reference; it does not define currency codes, minor units, redenomination or instrument behaviour.", "source_refs": [ "SRC-002", "SRC-011" ] }, { "neighbor": "WM-ECO-016 posting", "distinction": "The account supplies the container binding and selection criteria for its postings; posting lifecycle, reversal, matching and balance derivation stay in WM-ECO-016.", "source_refs": [ "SRC-001", "SRC-012" ] }, { "neighbor": "WM-XCT-014 parent exchange or transaction container", "distinction": "This model composes into the parent; cross-account orchestration and exchange-level semantics are not modelled here.", "source_refs": [ "SRC-001" ] }, { "neighbor": "Party and legal-entity identity master", "distinction": "The account carries role bindings and identifier references such as the LEI; it does not own party records, verification outcomes or corporate hierarchies.", "source_refs": [ "SRC-006", "SRC-010" ] }, { "neighbor": "Consent and data-access authorisation model", "distinction": "The account carries an access designation and a consent reference only; issuance, runtime evaluation, revocation and audit trails are owned by the authorisation model.", "source_refs": [ "SRC-002", "SRC-009", "SRC-014" ] }, { "neighbor": "Payment instruction and credit transfer model", "distinction": "The account is referenced as debtor or creditor account; instruction lifecycle, reachability and settlement remain outside.", "source_refs": [ "SRC-008", "SRC-012" ] }, { "neighbor": "Product and offering catalogue", "distinction": "The account carries a bound terms instance and product reference; generic product definition and tariff governance sit in the product model.", "source_refs": [ "SRC-003" ] }, { "neighbor": "Deposit guarantee scheme or deposit insurance model", "distinction": "The account carries scheme-scoped eligibility and ownership-category designation; coverage computation and payout are performed by the scheme.", "source_refs": [ "SRC-004", "SRC-007" ] }, { "neighbor": "Unclaimed property or reclaim fund model", "distinction": "The account carries dormancy inputs, the determination and a transfer reference; custody of transferred balances and the repayment obligation are external.", "source_refs": [ "SRC-005" ] } ] }, "sources": [ { "id": "SRC-001", "title": "FIBO FBC/ProductsAndServices/ClientsAndAccounts ontology", "organization": "EDM Council (standardised through OMG)", "url": "https://raw.githubusercontent.com/edmcouncil/fibo/master/FBC/ProductsAndServices/ClientsAndAccounts.rdf", "version_or_date": "Ontology version IRI FBC/20260701; retrieved from the master branch", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T10:00:00Z", "relevance": "Normative class and property definitions for Account, AccountHolder, AccountIdentifier, AccountProvider, CustomerAccount, DepositAccount, LoanOrCreditAccount, LedgerAccount, isHeldBy, isProvidedBy, hasPrimaryAccountHolder and hasSecondaryAccountHolder." }, { "id": "SRC-002", "title": "Open Banking Read/Write API v4.0 - Accounts resource and data model", "organization": "Open Banking Limited (UK)", "url": "https://openbankinguk.github.io/read-write-api-site3/v4.0/resources-and-data-models/aisp/Accounts.html", "version_or_date": "Read/Write API specification v4.0", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T10:05:00Z", "relevance": "Concrete account data model: immutable meaningless AccountId, Currency (ISO 4217, optional only for switched accounts), AccountCategory and AccountTypeCode, SchemeName choices (IBAN, SortCodeAccountNumber, PAN), Nickname, Description, Servicer BIC, Status with StatusUpdateDateTime, and permission-scoped field visibility." }, { "id": "SRC-003", "title": "Directive 2014/92/EU on comparability of fees, payment account switching and access to payment accounts with basic features", "organization": "European Union (Official Journal, EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014L0092", "version_or_date": "Adopted 23 July 2014; consolidated text on EUR-Lex", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T10:10:00Z", "relevance": "Defines a payment account, the payment account with basic features, the fee information document, the annual statement of fees, the switching service, the right of access and the limited grounds for refusal or termination of the framework contract." }, { "id": "SRC-004", "title": "Directive 2014/49/EU on deposit guarantee schemes", "organization": "European Union (Official Journal, EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014L0049", "version_or_date": "Adopted 16 April 2014", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T10:15:00Z", "relevance": "EUR 100 000 coverage per depositor per credit institution, exclusion of deposits of financial institutions and of money-laundering proceeds, per-depositor treatment of joint accounts, temporary high balances and the seven-working-day repayment deadline." }, { "id": "SRC-005", "title": "Dormant Bank and Building Society Accounts Act 2008, section 10 (Meaning of 'dormant')", "organization": "UK Parliament (legislation.gov.uk, The National Archives)", "url": "https://www.legislation.gov.uk/ukpga/2008/31/section/10", "version_or_date": "2008 c.31; section in force 12 March 2009", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T10:20:00Z", "relevance": "Statutory dormancy test: account open throughout 15 years with no holder-initiated transactions, exceptions for no-contact instructions and for terms preventing or penalising withdrawal, and the rule that bank-initiated closure still counts as open." }, { "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": "Current GLEIF publication, accessed 29 August 2026", "source_type": "registry", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T10:25:00Z", "relevance": "ISO 17442 twenty-character LEI as a governed global identifier for legal entities, with Level 1 'who is who' and Level 2 'who owns whom' reference data in the Global LEI Index." }, { "id": "SRC-007", "title": "FDIC - Financial products insured by the FDIC and deposit insurance ownership categories", "organization": "Federal Deposit Insurance Corporation (United States)", "url": "https://www.fdic.gov/resources/deposit-insurance/financial-products-insured/index.html", "version_or_date": "Current FDIC guidance, accessed 29 August 2026", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T10:30:00Z", "relevance": "Insured deposit product types and the USD 250 000 standard maximum per depositor per insured bank per ownership category, with the single, joint, trust, retirement, employee benefit, business and government ownership categories." }, { "id": "SRC-008", "title": "IBAN rules", "organization": "Deutsche Bundesbank", "url": "https://www.bundesbank.de/en/tasks/payment-systems/services/iban-rules", "version_or_date": "Current Bundesbank guidance, accessed 29 August 2026", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T10:35:00Z", "relevance": "Country-specific IBAN composition under ISO 13616: two-letter country code, two check digits and the national BBAN (for Germany an eight-digit bank sort code plus a ten-digit account number), with a separate check-digit calculation service." }, { "id": "SRC-009", "title": "Required Rulemaking on Personal Financial Data Rights (12 CFR part 1033)", "organization": "Consumer Financial Protection Bureau (United States)", "url": "https://www.consumerfinance.gov/rules-policy/final-rules/required-rulemaking-on-personal-financial-data-rights/", "version_or_date": "Final rule issued 22 October 2024; 89 FR 90838, published 18 November 2024", "source_type": "legislation", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T10:40:00Z", "relevance": "Defines covered accounts (Regulation E asset accounts, Regulation Z credit cards) and consumer-authorised access to account data including balance, account and routing number, transaction information and terms." }, { "id": "SRC-010", "title": "IEIM401505 - Financial Accounts: Introduction", "organization": "HM Revenue and Customs (UK)", "url": "https://www.gov.uk/hmrc-internal-manuals/international-exchange-of-information/ieim401505", "version_or_date": "HMRC internal manual, page updated 31 July 2026", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T10:45:00Z", "relevance": "CRS and FATCA account categories (depository, custodial, equity or debt interest, cash value insurance, annuity), excluded accounts, and the account holder to reportable account relationship." }, { "id": "SRC-011", "title": "IEIM401540 - Financial Accounts: Depository Account", "organization": "HM Revenue and Customs (UK)", "url": "https://www.gov.uk/hmrc-internal-manuals/international-exchange-of-information/ieim401540", "version_or_date": "HMRC internal manual, page updated 31 July 2026", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T10:50:00Z", "relevance": "Depository account definition covering current, savings, time and thrift accounts and certificates of deposit, non-dependence on interest, and the 1 January 2026 expansion to specified electronic money products and central bank digital currencies." }, { "id": "SRC-012", "title": "ISO 20022 Message Definitions catalogue (business areas including acmt Account Management and camt Cash Management)", "organization": "ISO 20022 Registration Authority", "url": "https://www.iso20022.org/iso-20022-message-definitions", "version_or_date": "Live catalogue, accessed 29 August 2026", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T10:55:00Z", "relevance": "Syntax-independent business components and message definitions for account opening, modification, mandate maintenance, switching and closing (acmt) and for account reporting and statements (camt); the catalogue page rendered only through search indexing during this research, so element-level detail is treated as an alignment rather than as verified text." }, { "id": "SRC-013", "title": "ISO 13616-1:2020 Financial services - International bank account number (IBAN) - Part 1: Structure of the IBAN", "organization": "International Organization for Standardization", "url": "https://www.iso.org/standard/81090.html", "version_or_date": "Second edition, published 2020", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T11:00:00Z", "relevance": "Normative structure of the IBAN and, with Part 2, the role of the Registration Authority that publishes national IBAN formats; the standard text is paywalled, so structural detail in this model is grounded in the Bundesbank rendering." }, { "id": "SRC-014", "title": "Personal Financial Data Rights Reconsideration (advance notice of proposed rulemaking)", "organization": "Consumer Financial Protection Bureau (United States)", "url": "https://www.consumerfinance.gov/rules-policy/rules-under-development/personal-financial-data-rights-reconsideration/", "version_or_date": "ANPR issued 22 August 2025", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T11:05:00Z", "relevance": "Evidence that the US account-data-sharing obligation is unsettled: the Bureau is reconsidering representative status, fees, data security and privacy, so conformance to 12 CFR part 1033 must not be asserted as settled fact." } ], "structure": { "bundles": [ { "id": "identity-and-classification", "name": "Account Identity and Classification", "description": "How an account is denoted, aliased and typed, across the identifier schemes and classification schemes that different authorities impose on the same account.", "rationale": "Account identifiers are scheme-bound and plural (immutable resource id, IBAN, domestic BBAN, PAN) and classification is authority-specific, so identity and typing must be modelled as scheme-qualified sets rather than single fields.", "source_refs": [ "SRC-001", "SRC-002", "SRC-008", "SRC-010", "SRC-013" ], "layers": [ { "id": "identifier-and-naming", "name": "Identifier Schemes and Naming", "description": "The identifier values that denote the account, their governing schemes, and the human-facing labels and proxies layered over them.", "source_refs": [ "SRC-001", "SRC-002", "SRC-008", "SRC-013" ], "findings": [ { "id": "account-identifier-schemes", "name": "Account identifier schemes and precedence", "description": "An account carries one authoritative servicer-assigned identifier plus zero or more scheme-governed public identifiers; each value must record its scheme, scheme owner and validity window.", "source_refs": [ "SRC-001", "SRC-002", "SRC-008", "SRC-013" ], "questions": [ { "id": "q-ident-master", "text": "Which identifier is the authoritative master-system identifier assigned by the account servicer, and in which namespace is it unique?", "kind": "identity", "answer_data": [ "Master-system identifier value", "Servicer namespace or system reference", "Uniqueness assertion scope" ] }, { "id": "q-ident-schemes", "text": "Which additional identifier schemes denote this account, and who governs each scheme?", "kind": "interoperability", "answer_data": [ "Scheme name (IBAN, BBAN, SortCodeAccountNumber, PAN, proprietary)", "Scheme owner or registration authority", "Identifier value and structure metadata" ] }, { "id": "q-ident-stability", "text": "Is each identifier immutable for the life of the account, or may it be reissued or reassigned?", "kind": "constraint", "answer_data": [ "Immutability flag per identifier", "Reassignment policy reference", "Superseded identifier history with validity window" ] }, { "id": "q-ident-time", "text": "From which instant is each identifier valid, and when did it cease to denote this account?", "kind": "temporal", "answer_data": [ "Identifier valid-from timestamp", "Identifier valid-to timestamp", "Observation timestamp of the identifier record" ] } ], "data_elements": [ { "id": "de-master-account-id", "name": "Master account identifier", "description": "Servicer-assigned identifier that authoritatively denotes the account within the servicing system.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "de-identifier-entry", "name": "Scheme-qualified identifier entry", "description": "Structured pair of scheme name and identifier value with validity window, for example an IBAN under ISO 13616.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-008", "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Identifiers are structured data values validated against external registries and schemes; there is no document instance to hold, and binding them to an artifact would wrongly imply the model issues or certifies them." }, { "id": "alias-proxy-and-display-names", "name": "Aliases, proxies and display labels", "description": "Non-authoritative labels attached to the account: customer nickname, servicer description, masked identifiers and proxy or alias values resolved to the account by an external directory.", "source_refs": [ "SRC-001", "SRC-002", "SRC-012" ], "questions": [ { "id": "q-alias-purpose", "text": "What is each alias or display label for, and is it customer-supplied or servicer-supplied?", "kind": "definition", "answer_data": [ "Label value", "Label origin (customer, servicer, scheme)", "Intended use context" ] }, { "id": "q-alias-resolve", "text": "Which external directory resolves a proxy or alias to this account, and what is the reference to that directory entry?", "kind": "relationship", "answer_data": [ "Proxy type code", "Directory or scheme reference", "Resolution record reference" ] }, { "id": "q-alias-mask", "text": "Which identifier values must be masked or truncated when displayed or shared?", "kind": "privacy", "answer_data": [ "Masking rule per identifier scheme", "Permitted display form", "Applicable disclosure context" ] } ], "data_elements": [ { "id": "de-account-nickname", "name": "Account nickname", "description": "Customer-assigned label with no authoritative meaning to the servicing system.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-proxy-alias", "name": "Proxy or alias entry", "description": "Alias value with its proxy type and the directory that resolves it to the account.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Labels, masks and proxy values are attribute data; the resolving directory is an external system referenced by identifier, so no artifact belongs to this model." } ] }, { "id": "classification-and-typing", "name": "Classification and Typing", "description": "Product, regulatory and tax classifications applied to the same account by different authorities, each with its own scheme, version and effective period.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-009", "SRC-010", "SRC-011" ], "findings": [ { "id": "product-and-regulatory-classification", "name": "Product and regulatory classification", "description": "Classification of the account by product family and subtype and by regulatory category such as payment account, payment account with basic features, deposit account, loan or credit account or internal ledger account.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-009" ], "questions": [ { "id": "q-class-product", "text": "Which product family and subtype does the servicer assign to this account, and under which code set?", "kind": "classification", "answer_data": [ "Product family code (for example CACC current account)", "Product subtype code", "Code set name and version" ] }, { "id": "q-class-regulatory", "text": "Which regulatory categories apply to the account in each jurisdiction where it is offered?", "kind": "authority", "answer_data": [ "Regulatory category code", "Issuing authority and instrument reference", "Jurisdiction identifier" ] }, { "id": "q-class-personal", "text": "Is the account held for personal or business purposes, and does that designation change the applicable rules?", "kind": "decision", "answer_data": [ "Account category (personal, business)", "Consequential rule set reference", "Designation basis" ] }, { "id": "q-class-effective", "text": "Over which effective period does each classification hold, and what triggered a reclassification?", "kind": "temporal", "answer_data": [ "Classification effective-from and effective-to", "Reclassification trigger reference", "Observation timestamp" ] } ], "data_elements": [ { "id": "de-product-type-code", "name": "Product type code", "description": "Scheme-qualified product family or subtype code assigned by the servicer.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-regulatory-category", "name": "Regulatory classification entry", "description": "Regulatory category with issuing authority, jurisdiction and effective period.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Classification is coded reference data assigned against external code sets; the code sets themselves are governed by their publishers and are aligned, not reproduced, by this model." }, { "id": "tax-status-classification", "name": "Tax reporting status and self-certification", "description": "The account's status under automatic exchange of information regimes: financial account category, reportable or excluded status, and the self-certification that supports it.", "source_refs": [ "SRC-010", "SRC-011" ], "questions": [ { "id": "q-tax-category", "text": "Which financial account category applies for automatic exchange of information purposes?", "kind": "classification", "answer_data": [ "Category (depository, custodial, equity or debt interest, cash value insurance, annuity)", "Regime name (CRS, FATCA or domestic equivalent)", "Category effective period" ] }, { "id": "q-tax-excluded", "text": "Is the account an excluded account, and on what documented basis?", "kind": "exception", "answer_data": [ "Excluded account flag", "Exclusion basis reference", "Reviewing authority guidance reference" ] }, { "id": "q-tax-cert", "text": "What self-certification or documentary evidence establishes the account holder's tax residence?", "kind": "evidence", "answer_data": [ "Self-certification record reference", "Declared tax residence jurisdictions", "Certification collection timestamp" ] }, { "id": "q-tax-newaccount", "text": "Is the account pre-existing or new relative to the applicable regime start date, and which due-diligence path follows?", "kind": "process", "answer_data": [ "Pre-existing or new designation", "Regime start date reference", "Due-diligence path identifier" ] } ], "data_elements": [ { "id": "de-tax-account-category", "name": "Financial account category", "description": "Category of the account under the applicable exchange-of-information regime.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "de-tax-residence-claim", "name": "Declared tax residence", "description": "Jurisdiction or jurisdictions of tax residence claimed for the account holder or controlling persons.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "tax-self-certification-record", "name": "Tax residence self-certification record", "description": "Holder-signed or electronically captured declaration of tax residence and status used to classify the account for exchange-of-information purposes.", "media_or_form": [ "signed declaration form", "structured self-certification record" ], "serial": false, "identity_strategy": "Master-system self-certification record identifier where one exists; otherwise a ULID assigned by the adopting Dimension, with supersession recorded rather than overwriting.", "source_refs": [ "SRC-010", "SRC-011" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "parties-and-authority", "name": "Parties, Ownership and Operating Authority", "description": "Who holds the account, who really controls it, who services it, and who is permitted to operate it.", "rationale": "Ownership, beneficial control and operating authority are three distinct role structures with different legal sources and different consequences for protection, tax and access, and each must be a reference to a party rather than a copy of party data.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-006", "SRC-007", "SRC-010" ], "layers": [ { "id": "holders-and-ownership", "name": "Holders and Ownership Structure", "description": "The set of parties that own the account, how ownership is shared, and who ultimately controls or benefits from it.", "source_refs": [ "SRC-001", "SRC-004", "SRC-006", "SRC-007", "SRC-010" ], "findings": [ { "id": "holders-and-ownership-structure", "name": "Account holders and ownership structure", "description": "The holder set with primary and secondary roles, the ownership form (single, joint, trust, entity, government), declared shares, and the ownership category used by protection schemes.", "source_refs": [ "SRC-001", "SRC-004", "SRC-007" ], "questions": [ { "id": "q-hold-who", "text": "Which parties hold this account, and which holder is primary?", "kind": "ownership", "answer_data": [ "Party identifier per holder", "Holder role (primary, secondary)", "Role effective period" ] }, { "id": "q-hold-form", "text": "What ownership form does the account take, and which protection-scheme ownership category follows from it?", "kind": "classification", "answer_data": [ "Ownership form code", "Protection-scheme ownership category", "Scheme jurisdiction" ] }, { "id": "q-hold-share", "text": "How is entitlement divided between holders when shares are not equal?", "kind": "composition", "answer_data": [ "Declared share per holder", "Basis of the share declaration", "Default rule applied when undeclared" ] }, { "id": "q-hold-change", "text": "What event added or removed a holder, and when did the change take effect?", "kind": "event", "answer_data": [ "Change event type", "Event timestamp", "Instructing or authorising party reference" ] } ], "data_elements": [ { "id": "de-holder-binding", "name": "Holder role binding", "description": "Reference to a party with holder role, share and validity window; party master data stays external.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "de-ownership-form", "name": "Ownership form", "description": "Coded ownership structure of the account, such as single, joint, revocable trust or corporate.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Holder structure is a set of typed references to parties governed by a separate party model; the underlying agreement is carried once by the opening record rather than duplicated here." }, { "id": "beneficial-owners-and-controlling-persons", "name": "Beneficial owners and controlling persons", "description": "Natural persons who ultimately own or control an entity holder, recorded as references with the threshold, prong and regime that produced the determination.", "source_refs": [ "SRC-006", "SRC-010" ], "questions": [ { "id": "q-bo-who", "text": "Which natural persons are recorded as beneficial owners or controlling persons of an entity holder?", "kind": "ownership", "answer_data": [ "Party identifier per person", "Role type (ownership prong, control prong, controlling person)", "Determination effective period" ] }, { "id": "q-bo-threshold", "text": "Which ownership threshold and regime produced each determination?", "kind": "authority", "answer_data": [ "Threshold percentage applied", "Regime and instrument reference", "Determining jurisdiction" ] }, { "id": "q-bo-chain", "text": "Through which intermediate entities does control reach the account, and how is that chain referenced?", "kind": "relationship", "answer_data": [ "Intermediate entity identifiers (for example LEI)", "Relationship type per link", "External ownership-data source reference" ] }, { "id": "q-bo-refresh", "text": "When was the beneficial ownership record last confirmed, and what triggers re-confirmation?", "kind": "temporal", "answer_data": [ "Last confirmation timestamp", "Re-confirmation trigger list", "Next scheduled review date" ] } ], "data_elements": [ { "id": "de-beneficial-owner-binding", "name": "Beneficial owner or controlling person binding", "description": "Reference to a natural person with the role, threshold and regime that produced the determination.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "de-control-chain-link", "name": "Control chain link", "description": "Reference to an intermediate legal entity, preferably by LEI, on the path from holder to controlling person.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "beneficial-ownership-certification", "name": "Beneficial ownership certification record", "description": "Certification captured at account opening or refresh identifying the natural persons who own or control an entity holder.", "media_or_form": [ "certification form", "structured certification record" ], "serial": false, "identity_strategy": "Master-system certification identifier where the onboarding system assigns one; otherwise a Dimension-assigned ULID, with each refresh recorded as a new superseding instance.", "source_refs": [ "SRC-006", "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "id": "servicing-and-mandates", "name": "Servicing and Operating Authority", "description": "The institution that maintains the account and the authority granted to parties to operate it.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-012" ], "findings": [ { "id": "account-servicer-and-provider", "name": "Account servicer and provider", "description": "The institution that maintains the account and any branch, agent or sub-servicer arrangement, identified by governed institution identifiers.", "source_refs": [ "SRC-001", "SRC-002" ], "questions": [ { "id": "q-srv-who", "text": "Which institution services this account, and by which governed identifier is it denoted?", "kind": "identity", "answer_data": [ "Servicer institution identifier (BIC, LEI, national code)", "Identifier scheme", "Servicer legal name" ] }, { "id": "q-srv-branch", "text": "At which branch, booking location or jurisdiction is the account maintained?", "kind": "spatial", "answer_data": [ "Branch or booking location identifier", "Jurisdiction code", "Location effective period" ] }, { "id": "q-srv-delegate", "text": "Is any part of servicing delegated to an agent, sub-servicer or platform, and under what reference?", "kind": "relationship", "answer_data": [ "Delegate party identifier", "Delegated function description", "Arrangement reference" ] } ], "data_elements": [ { "id": "de-servicer-reference", "name": "Servicer reference", "description": "Reference to the servicing institution using a governed identifier scheme.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "de-booking-jurisdiction", "name": "Booking jurisdiction", "description": "Jurisdiction in which the account is maintained, driving applicable rules and protections.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "The servicer is an external legal entity referenced by a governed identifier; institution master data and licensing evidence belong to the party and authorisation models." }, { "id": "mandates-and-operating-authority", "name": "Mandates and operating authority", "description": "Grants of authority to operate the account: signatories, powers of attorney, guardianship, delegated limits and joint-signature requirements.", "source_refs": [ "SRC-001", "SRC-003", "SRC-012" ], "questions": [ { "id": "q-man-who", "text": "Which parties may instruct on this account, and with what scope of authority?", "kind": "authority", "answer_data": [ "Authorised party reference", "Authority scope description", "Permitted instruction types" ] }, { "id": "q-man-combination", "text": "Does an instruction require more than one authorised signature, and under what combination rule?", "kind": "constraint", "answer_data": [ "Signature combination rule", "Threshold or quorum value", "Value band to which the rule applies" ] }, { "id": "q-man-source", "text": "Which instrument grants the authority, and does it originate from the holder, a court or a statute?", "kind": "provenance", "answer_data": [ "Granting instrument reference", "Grant origin type", "Granting party or authority identifier" ] }, { "id": "q-man-end", "text": "When does the mandate expire, and what event revokes it?", "kind": "lifecycle", "answer_data": [ "Mandate valid-from and valid-to", "Revocation event type", "Revocation record reference" ] } ], "data_elements": [ { "id": "de-mandate-entry", "name": "Mandate entry", "description": "Authority grant with authorised party reference, scope, combination rule and validity window.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-012" ] }, { "id": "de-authority-scope-code", "name": "Authority scope code", "description": "Coded scope of permitted operations, for example view only, initiate payments, amend terms or close.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "mandate-instrument", "name": "Mandate or authority instrument", "description": "The signed or certified instrument that grants operating authority, such as a signature mandate, power of attorney or court appointment.", "media_or_form": [ "signed mandate document", "court or statutory appointment record", "structured mandate record" ], "serial": false, "identity_strategy": "Master-system mandate identifier from the servicing system; otherwise a Dimension-assigned ULID. Amendments create a new versioned instance linked to its predecessor.", "source_refs": [ "SRC-003", "SRC-012" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "denomination-terms-and-protection", "name": "Denomination, Terms and Protection", "description": "What the account is denominated in, the terms and limits that bind it, and the protection scheme designation that applies to its balances.", "rationale": "Denomination, pricing, limits and depositor protection are the operating rules that make an account usable, and each is set by a different authority: the servicer, the contract and the guarantee scheme.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-005", "SRC-007", "SRC-011" ], "layers": [ { "id": "denomination-scope", "name": "Denomination and Instrument Scope", "description": "The monetary unit or instrument in which the account is expressed and the set of instruments it may hold, carried strictly as references.", "source_refs": [ "SRC-002", "SRC-011" ], "findings": [ { "id": "denomination-and-permitted-instruments", "name": "Denomination and permitted monetary instruments", "description": "The account's denomination reference and any permitted additional instruments, including electronic money products and central bank digital currencies where the regime recognises them.", "source_refs": [ "SRC-002", "SRC-011", "SRC-001" ], "questions": [ { "id": "q-den-unit", "text": "In which monetary unit or instrument is this account denominated, and how is that unit referenced?", "kind": "definition", "answer_data": [ "Denomination reference to the monetary unit model", "Reference scheme and version", "Reference resolution timestamp" ] }, { "id": "q-den-multi", "text": "May the account hold more than one denomination simultaneously, and how are sub-balances distinguished?", "kind": "composition", "answer_data": [ "Multi-denomination permitted flag", "Sub-balance partition key", "Partition rule reference" ] }, { "id": "q-den-instrument", "text": "Which instrument classes may be held, such as deposit claims, electronic money products or central bank digital currency?", "kind": "constraint", "answer_data": [ "Permitted instrument class list", "Regime that recognises the class", "Effective date of recognition" ] }, { "id": "q-den-change", "text": "Under what conditions may the denomination change, and what record captures the change?", "kind": "exception", "answer_data": [ "Permitted change conditions", "Change authorisation reference", "Change effective timestamp" ] } ], "data_elements": [ { "id": "de-denomination-reference", "name": "Denomination reference", "description": "Reference to the monetary unit or instrument model entry that denominates the account; no unit semantics are carried locally.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-011" ] }, { "id": "de-multi-denomination-flag", "name": "Multi-denomination indicator", "description": "Whether the account may carry balances in more than one denomination at the same time.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "This finding is a pure outbound reference to WM-ECO-004; reproducing unit codes, minor units or instrument behaviour here would duplicate the target model and break the reference contract." } ] }, { "id": "contractual-terms", "name": "Contractual Terms, Pricing and Limits", "description": "The priced terms and the operating constraints that the servicer applies to the account.", "source_refs": [ "SRC-001", "SRC-003", "SRC-005" ], "findings": [ { "id": "pricing-and-interest-terms", "name": "Pricing, fees and interest terms", "description": "Fee items, charging basis and interest terms bound to the account, together with the pre-contract fee disclosure and the periodic statement of fees required in some jurisdictions.", "source_refs": [ "SRC-003" ], "questions": [ { "id": "q-fee-items", "text": "Which fee items apply to this account and on what charging basis?", "kind": "measurement", "answer_data": [ "Fee item name using standardised terminology", "Unit fee amount and denomination reference", "Charging frequency or trigger" ] }, { "id": "q-fee-interest", "text": "What interest rates apply to credit and debit balances, and how are they determined?", "kind": "requirement", "answer_data": [ "Rate value or reference rate", "Rate determination basis", "Rate effective period" ] }, { "id": "q-fee-disclose", "text": "Which pre-contract disclosure was provided, and when was it supplied to the holder?", "kind": "evidence", "answer_data": [ "Disclosure document reference", "Provision timestamp", "Disclosure version" ] }, { "id": "q-fee-period", "text": "Over which period does each periodic fee statement report, and how often must it be issued?", "kind": "temporal", "answer_data": [ "Reporting period start and end", "Issue frequency", "Issue timestamp" ] } ], "data_elements": [ { "id": "de-fee-item", "name": "Fee item", "description": "A single priced service on the account with amount, basis and effective period.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-interest-term", "name": "Interest term", "description": "Applicable credit or debit interest rate with its determination basis and effective period.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "fee-information-document", "name": "Fee information document", "description": "Pre-contract document setting out the fees for the most representative services in standardised terminology.", "media_or_form": [ "standardised disclosure document" ], "serial": false, "identity_strategy": "Servicer document identifier plus version; where absent, a Dimension-assigned ULID with an explicit version label. Supersession is recorded, not overwritten.", "source_refs": [ "SRC-003" ] }, { "id": "statement-of-fees", "name": "Statement of fees", "description": "Periodic statement of all fees incurred, usage frequency and applicable interest rates for the reporting period.", "media_or_form": [ "periodic statement document", "structured fee statement record" ], "serial": true, "identity_strategy": "Servicer statement identifier; serial instances are named by account identifier plus reporting period start and end plus sequence number, never by issue date alone.", "source_refs": [ "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "limits-and-operating-constraints", "name": "Limits, facilities and operating constraints", "description": "Quantitative and behavioural constraints on the account: credit or overdraft limits, transaction and balance limits, notice periods and withdrawal restrictions or penalties.", "source_refs": [ "SRC-001", "SRC-003", "SRC-005" ], "questions": [ { "id": "q-lim-credit", "text": "What credit or overdraft facility is attached, and what is its limit and expiry?", "kind": "constraint", "answer_data": [ "Facility limit quantity with denomination reference", "Facility type", "Facility expiry timestamp" ] }, { "id": "q-lim-txn", "text": "Which transaction, frequency or balance limits constrain use of the account?", "kind": "requirement", "answer_data": [ "Limit type", "Limit value and measurement window", "Limit source (contract, regulation, holder instruction)" ] }, { "id": "q-lim-withdraw", "text": "Do the account terms prevent withdrawal or impose a penalty or disincentive on withdrawal?", "kind": "constraint", "answer_data": [ "Withdrawal restriction flag", "Notice period duration", "Penalty description" ] }, { "id": "q-lim-basic", "text": "Which minimum service set must the account provide if it is a regulated basic-features account?", "kind": "requirement", "answer_data": [ "Mandated service list", "Regulatory basis reference", "Applicable jurisdiction" ] } ], "data_elements": [ { "id": "de-limit-entry", "name": "Limit entry", "description": "A typed limit with value, measurement window, source and effective period.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-withdrawal-restriction", "name": "Withdrawal restriction", "description": "Notice period or penalty applying to withdrawals, which also affects dormancy determination.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Limits are parameter values bound to the account; the contractual document that establishes them is carried once by the opening record and the fee disclosure rather than duplicated here." } ] }, { "id": "protection-designation", "name": "Protection and Guarantee Designation", "description": "The depositor protection or guarantee scheme designation attached to the account and the evidence that the holder was informed of it.", "source_refs": [ "SRC-004", "SRC-007" ], "findings": [ { "id": "deposit-protection-designation", "name": "Deposit protection and guarantee designation", "description": "Which protection scheme covers the account, which eligibility and ownership category applies, and what information the holder acknowledged; coverage computation stays with the scheme.", "source_refs": [ "SRC-004", "SRC-007" ], "questions": [ { "id": "q-prot-scheme", "text": "Which deposit guarantee or insurance scheme covers this account, and in which jurisdiction?", "kind": "authority", "answer_data": [ "Scheme identifier and operating body", "Jurisdiction code", "Designation effective period" ] }, { "id": "q-prot-eligible", "text": "Is the account an eligible or excluded deposit under the scheme, and on what basis?", "kind": "classification", "answer_data": [ "Eligibility status", "Exclusion basis where applicable", "Determining rule reference" ] }, { "id": "q-prot-category", "text": "Which ownership or aggregation category does the account fall into for coverage purposes?", "kind": "classification", "answer_data": [ "Ownership category code", "Per-depositor aggregation rule reference", "Category effective period" ] }, { "id": "q-prot-temporary", "text": "Is any balance flagged as temporarily protected above the standard limit, and for how long?", "kind": "exception", "answer_data": [ "Temporary high balance flag", "Qualifying reason code", "Protection window start and end" ] } ], "data_elements": [ { "id": "de-protection-designation", "name": "Protection scheme designation", "description": "Scheme reference with eligibility status, ownership category and effective period; no coverage amount is computed here.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-007" ] }, { "id": "de-temporary-protection-window", "name": "Temporary protection window", "description": "Period during which a qualifying balance attracts protection above the standard limit.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "depositor-information-sheet", "name": "Depositor information sheet", "description": "Standardised information on protection scheme coverage supplied to and acknowledged by the depositor.", "media_or_form": [ "standardised information sheet", "acknowledgement record" ], "serial": false, "identity_strategy": "Servicer document identifier plus version; otherwise a Dimension-assigned ULID with version label and the acknowledgement timestamp recorded separately from the issue timestamp.", "source_refs": [ "SRC-004" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "state-and-lifecycle", "name": "State, Lifecycle and Time", "description": "The account's status model, restrictions, opening, closure, switching and dormancy determination, with event time separated from observation time throughout.", "rationale": "Account status drives whether any other context is actionable, and no single normative status code list exists across jurisdictions and interfaces, so state must be modelled explicitly with its source and timing.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-005", "SRC-012" ], "layers": [ { "id": "state-model", "name": "Status and Restrictions", "description": "The current operating state of the account and any restriction, freeze or hold that narrows what may be done with it.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004" ], "findings": [ { "id": "account-status-and-transitions", "name": "Account status and state transitions", "description": "The account's current status, the permitted transitions between statuses, and the timestamps that distinguish when a change occurred from when it was observed.", "source_refs": [ "SRC-001", "SRC-002" ], "questions": [ { "id": "q-st-current", "text": "What is the account's current status, and under which status code set is it expressed?", "kind": "state", "answer_data": [ "Status code value", "Status code set name and version", "Status update timestamp" ] }, { "id": "q-st-transitions", "text": "Which status transitions are permitted, and which are terminal?", "kind": "lifecycle", "answer_data": [ "Permitted transition pairs", "Terminal status list", "Transition precondition description" ] }, { "id": "q-st-observe", "text": "When did the status change take effect, and when was the change observed or ingested by this model?", "kind": "temporal", "answer_data": [ "Event timestamp of the transition", "Observation or ingestion timestamp", "Reporting source reference" ] }, { "id": "q-st-consequence", "text": "Which capabilities are suspended or enabled by the current status?", "kind": "decision", "answer_data": [ "Capability list affected", "Effect per capability", "Rule reference" ] } ], "data_elements": [ { "id": "de-account-status", "name": "Account status", "description": "Scheme-qualified status value for the account, such as enabled, disabled, dormant or closed.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-status-event-time", "name": "Status event timestamp", "description": "Instant at which the status change took effect, recorded separately from the observation timestamp.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Status is a coded attribute with timestamps; the instructions and notices that cause transitions are carried by the opening, closure and restriction findings or by external models." }, { "id": "restriction-freeze-and-hold-designation", "name": "Restrictions, freezes and holds", "description": "Designation that the account is blocked, frozen or restricted, with the scope, the authority behind it and a reference to the originating order, which this model does not own.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004" ], "questions": [ { "id": "q-res-scope", "text": "What scope of activity is restricted: all activity, debits only, or specified counterparties or amounts?", "kind": "constraint", "answer_data": [ "Restriction scope code", "Restricted operation list", "Threshold or counterparty qualifier" ] }, { "id": "q-res-authority", "text": "Which authority or contractual ground supports the restriction?", "kind": "authority", "answer_data": [ "Authority type (court, regulator, servicer, holder)", "Legal or contractual ground reference", "Order or instruction reference" ] }, { "id": "q-res-duration", "text": "How long does the restriction last, and what condition lifts it?", "kind": "temporal", "answer_data": [ "Restriction start and expected end timestamps", "Release condition description", "Release record reference" ] }, { "id": "q-res-disclose", "text": "May the restriction and its reason be disclosed to the account holder?", "kind": "privacy", "answer_data": [ "Disclosure permitted flag", "Disclosure restriction basis", "Permitted disclosure recipients" ] } ], "data_elements": [ { "id": "de-restriction-entry", "name": "Restriction entry", "description": "Scope, ground, authority reference and validity window of a restriction on the account.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] }, { "id": "de-restriction-order-reference", "name": "Originating order reference", "description": "Pointer to the court order, regulatory instruction or internal decision that imposed the restriction.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "The originating orders and notices are records of courts, regulators or a case-management model; this model carries only the designation and a reference, and it does not enforce or evaluate the restriction at runtime." } ] }, { "id": "opening-closure-and-switching", "name": "Opening, Closure and Switching", "description": "The bounding events of the account relationship and the portability of the arrangement to another provider.", "source_refs": [ "SRC-002", "SRC-003", "SRC-010", "SRC-012" ], "findings": [ { "id": "opening-and-onboarding-record", "name": "Opening and onboarding record", "description": "The account opening decision, its date, the framework contract concluded and the grounds relied on where opening was refused or conditional.", "source_refs": [ "SRC-003", "SRC-010", "SRC-012" ], "questions": [ { "id": "q-open-when", "text": "On which date was the account opened, and from which instant was it operable?", "kind": "event", "answer_data": [ "Opening event timestamp", "First operable timestamp", "Recording or ingestion timestamp" ] }, { "id": "q-open-contract", "text": "Which framework contract or agreement governs the account, and in which version?", "kind": "provenance", "answer_data": [ "Contract reference and version", "Contract conclusion timestamp", "Governing law and jurisdiction" ] }, { "id": "q-open-refusal", "text": "If an application was refused or conditionally accepted, on what permitted ground?", "kind": "exception", "answer_data": [ "Decision outcome", "Permitted ground reference", "Decision timestamp and notifying party" ] }, { "id": "q-open-channel", "text": "Through which channel and instruction was the account opened?", "kind": "process", "answer_data": [ "Opening channel code", "Opening instruction message reference", "Instructing party reference" ] } ], "data_elements": [ { "id": "de-opening-timestamp", "name": "Opening timestamp", "description": "Instant at which the account relationship came into existence.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-framework-contract-reference", "name": "Framework contract reference", "description": "Reference and version of the contract that governs the account relationship.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "account-agreement", "name": "Account agreement or framework contract", "description": "The executed agreement establishing the account relationship, its terms and the governing law.", "media_or_form": [ "executed contract document", "structured contract record" ], "serial": false, "identity_strategy": "Servicer contract identifier plus version; otherwise a Dimension-assigned ULID. Each amendment is a new version linked to its predecessor rather than an edit in place.", "source_refs": [ "SRC-003", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "closure-and-termination-record", "name": "Closure and termination record", "description": "The termination of the account relationship: who initiated it, on what ground, what notice was given and how the residual balance was directed.", "source_refs": [ "SRC-003", "SRC-012" ], "questions": [ { "id": "q-close-who", "text": "Who initiated closure, and on what contractual or legal ground?", "kind": "decision", "answer_data": [ "Initiating party reference", "Ground code and instrument reference", "Decision timestamp" ] }, { "id": "q-close-notice", "text": "What notice period applied, and when was notice given to the holder?", "kind": "temporal", "answer_data": [ "Notice period duration", "Notice issue timestamp", "Notice delivery evidence reference" ] }, { "id": "q-close-residual", "text": "Where was any residual balance directed on closure?", "kind": "process", "answer_data": [ "Destination account or instrument reference", "Residual amount with denomination reference", "Transfer instruction reference" ] }, { "id": "q-close-final", "text": "Is closure reversible, and what identifier remains resolvable after closure?", "kind": "lifecycle", "answer_data": [ "Reversibility flag and window", "Retained identifier set", "Post-closure resolution behaviour" ] } ], "data_elements": [ { "id": "de-closure-timestamp", "name": "Closure timestamp", "description": "Instant at which the account ceased to be operable, distinct from the record archival timestamp.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-closure-ground", "name": "Closure ground", "description": "Coded ground for termination, restricted in some jurisdictions to specified lawful reasons.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "closure-confirmation", "name": "Closure notice and confirmation", "description": "Notice of termination and the confirmation that the account was closed and the residual balance directed.", "media_or_form": [ "notice document", "closure confirmation record" ], "serial": false, "identity_strategy": "Servicer closure case identifier; otherwise a Dimension-assigned ULID, with notice and confirmation recorded as separate instances carrying their own timestamps.", "source_refs": [ "SRC-003", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "switching-and-portability", "name": "Switching and portability", "description": "Transfer of the account arrangement to another provider: authorisation, the items to be moved, redirection of incoming payments and the effect on identifiers.", "source_refs": [ "SRC-002", "SRC-003", "SRC-012" ], "questions": [ { "id": "q-sw-auth", "text": "What authorisation did the holder give to the receiving provider to run the switch?", "kind": "authority", "answer_data": [ "Switch authorisation reference", "Authorising holder reference", "Authorisation timestamp" ] }, { "id": "q-sw-items", "text": "Which recurring arrangements and balances are in scope of the switch?", "kind": "composition", "answer_data": [ "Standing order and direct debit reference list", "Balance transfer instruction reference", "Item inclusion decision per arrangement" ] }, { "id": "q-sw-redirect", "text": "For how long are incoming payments redirected, and by which mechanism?", "kind": "process", "answer_data": [ "Redirection window start and end", "Redirection mechanism description", "Old and new account identifier references" ] }, { "id": "q-sw-identifier", "text": "Does the account identifier survive the switch, and if not how are old references resolved?", "kind": "identity", "answer_data": [ "Identifier portability flag", "Superseded identifier record", "Resolution behaviour for stale references" ] } ], "data_elements": [ { "id": "de-switch-case-reference", "name": "Switch case reference", "description": "Reference to the switching case run between the transferring and receiving providers.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-redirection-window", "name": "Redirection window", "description": "Period during which payments addressed to the old account identifier are redirected.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "switching-authority-pack", "name": "Switching authority and switching pack", "description": "Holder authorisation and the accompanying set of arrangements, balances and redirection instructions exchanged between providers.", "media_or_form": [ "authorisation document", "structured switching instruction set" ], "serial": false, "identity_strategy": "Switching scheme case identifier where the scheme assigns one; otherwise a Dimension-assigned ULID, keyed to the transferring and receiving account references.", "source_refs": [ "SRC-003", "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "dormancy-and-disposition", "name": "Dormancy and Balance Disposition", "description": "Determination that an account is dormant or abandoned and the reference to any statutory transfer of its balance.", "source_refs": [ "SRC-001", "SRC-005" ], "findings": [ { "id": "dormancy-and-escheatment-designation", "name": "Dormancy determination and escheatment linkage", "description": "The inactivity inputs, jurisdictional test and resulting dormancy designation, plus a reference to any transfer of the balance to a reclaim fund or state administrator.", "source_refs": [ "SRC-001", "SRC-005" ], "questions": [ { "id": "q-dorm-last", "text": "When did the holder last initiate a transaction or otherwise engage with the account?", "kind": "temporal", "answer_data": [ "Last holder-initiated activity timestamp", "Activity type", "Source system of the activity signal" ] }, { "id": "q-dorm-test", "text": "Which jurisdictional inactivity test applies, and over what period?", "kind": "requirement", "answer_data": [ "Inactivity period duration", "Statutory or scheme reference", "Applicable jurisdiction" ] }, { "id": "q-dorm-except", "text": "Does an exception prevent dormancy, such as a no-contact instruction or terms that block or penalise withdrawal?", "kind": "exception", "answer_data": [ "Exception type", "Supporting instruction or term reference", "Exception effective period" ] }, { "id": "q-dorm-transfer", "text": "Was the balance transferred to a reclaim fund or administrator, and what reclaim reference preserves the holder's right to repayment?", "kind": "ownership", "answer_data": [ "Transfer event reference", "Receiving fund or administrator identifier", "Reclaim reference retained for the holder" ] } ], "data_elements": [ { "id": "de-last-activity-timestamp", "name": "Last holder-initiated activity timestamp", "description": "Instant of the most recent transaction or engagement initiated by the holder, the primary input to the dormancy test.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-dormancy-designation", "name": "Dormancy designation", "description": "Designation with the applied test, the determination outcome and the determination timestamp.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Dormancy is a determination expressed as data over activity timestamps and a jurisdictional rule; the transfer of the balance and the resulting custody and repayment obligation are executed and evidenced by the reclaim fund or administrator, not by this model." } ] } ] }, { "id": "position-and-contained-records", "name": "Position Expression and Contained Records", "description": "How the account expresses balances as observations and how it binds to the postings it contains without absorbing their semantics.", "rationale": "The account is a container for records; balances are reported observations with a type and an as-of instant, while their derivation and the postings themselves belong to the contained posting model.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-009", "SRC-012" ], "layers": [ { "id": "position-expression", "name": "Balance and Statement Declaration", "description": "Typed balance observations and the designation of periodic statements reporting them.", "source_refs": [ "SRC-002", "SRC-003", "SRC-009" ], "findings": [ { "id": "balance-and-statement-declaration", "name": "Declared balances and statement designation", "description": "Balance observations qualified by balance type, denomination reference and as-of instant, plus the designation and delivery arrangement of periodic account statements.", "source_refs": [ "SRC-002", "SRC-003", "SRC-009", "SRC-012" ], "questions": [ { "id": "q-bal-type", "text": "Which balance types does this account report, such as booked, available or pending?", "kind": "measurement", "answer_data": [ "Balance type code and code set", "Balance amount with denomination reference", "Credit or debit indicator" ] }, { "id": "q-bal-asof", "text": "As of which instant does each balance hold, and when was it observed by this model?", "kind": "temporal", "answer_data": [ "Balance as-of timestamp", "Observation or ingestion timestamp", "Source system reference" ] }, { "id": "q-bal-derive", "text": "Which model derives the balance from underlying entries, and is the value reported or recomputed here?", "kind": "provenance", "answer_data": [ "Derivation owner model reference", "Reported or recomputed indicator", "Reconciliation status" ] }, { "id": "q-bal-statement", "text": "Over which period and at what frequency are statements issued for this account, and to whom?", "kind": "process", "answer_data": [ "Statement period start and end", "Issue frequency", "Recipient and delivery designation" ] } ], "data_elements": [ { "id": "de-balance-observation", "name": "Balance observation", "description": "Typed balance with amount, denomination reference, as-of instant and observation instant.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-009" ] }, { "id": "de-statement-designation", "name": "Statement designation", "description": "Frequency, period basis, recipients and delivery arrangement for periodic statements.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] } ], "artifacts": [ { "id": "account-statement", "name": "Account statement", "description": "Periodic statement reporting opening and closing balances and the entries for a defined period.", "media_or_form": [ "statement document", "structured account report message" ], "serial": true, "identity_strategy": "Servicer statement identifier where assigned; serial instances are named by account identifier plus period start and end plus a monotonic sequence number, never by issue date alone. Entry content is owned by the posting model.", "source_refs": [ "SRC-002", "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "contained-record-binding", "name": "Contained Record Binding", "description": "The declared binding between the account and the postings it contains.", "source_refs": [ "SRC-001", "SRC-012" ], "findings": [ { "id": "posting-container-binding", "name": "Posting container binding", "description": "The reference and selection criteria by which the account's contained postings are located in WM-ECO-016, with no local posting semantics.", "source_refs": [ "SRC-001", "SRC-012" ], "questions": [ { "id": "q-post-locate", "text": "By which key are the postings belonging to this account selected in the contained posting model?", "kind": "composition", "answer_data": [ "Selection key definition", "Contained model reference", "Key stability assertion" ] }, { "id": "q-post-boundary", "text": "Which posting attributes may this model read, and which operations remain exclusive to the posting model?", "kind": "relationship", "answer_data": [ "Readable attribute list", "Prohibited operation list", "Boundary rationale reference" ] }, { "id": "q-post-partition", "text": "Are contained postings partitioned by denomination, sub-account or ledger dimension?", "kind": "classification", "answer_data": [ "Partition dimension list", "Partition key values", "Partition rule reference" ] }, { "id": "q-post-consistency", "text": "How is a mismatch between a declared balance and the contained postings recorded rather than silently corrected?", "kind": "quality", "answer_data": [ "Discrepancy record structure", "Detection timestamp", "Owning model for resolution" ] } ], "data_elements": [ { "id": "de-posting-collection-reference", "name": "Posting collection reference", "description": "Reference to the contained posting set together with the selection key that resolves it.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-012" ] }, { "id": "de-ledger-partition-key", "name": "Ledger partition key", "description": "Optional key partitioning contained postings, for example by denomination or sub-ledger.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "This finding is a pure containment binding to WM-ECO-016; holding a posting artifact here would reproduce the contained model's records and violate the ledger matryoshka contract." } ] } ] }, { "id": "governance-evidence-and-interoperability", "name": "Provenance, Evidence, Retention, Access and Alignment", "description": "How account context is sourced, evidenced, validated, retained, shared and mapped to external representations.", "rationale": "Account records are asserted by systems and disclosed under regulation, so provenance, evidence linkage, validation, retention designation, access designation and standards crosswalks are needed to make the model auditable and portable without absorbing enforcement.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-005", "SRC-008", "SRC-009", "SRC-010", "SRC-012", "SRC-013", "SRC-014" ], "layers": [ { "id": "provenance-evidence-and-retention", "name": "Provenance, Evidence and Retention", "description": "Where each assertion came from, what evidence supports it, and how long the record must be kept.", "source_refs": [ "SRC-002", "SRC-004", "SRC-005", "SRC-009", "SRC-010" ], "findings": [ { "id": "record-provenance-and-source-system", "name": "Record provenance and source system", "description": "For each asserted element, the source system, asserting party, assertion time and ingestion time, so that conflicting reports about the same account can be adjudicated.", "source_refs": [ "SRC-001", "SRC-002", "SRC-012" ], "questions": [ { "id": "q-prov-source", "text": "Which system of record asserted this element, and which party operates it?", "kind": "provenance", "answer_data": [ "Source system identifier", "Operating party reference", "Interface or message reference" ] }, { "id": "q-prov-time", "text": "When was the value asserted at source, and when was it ingested into this model?", "kind": "temporal", "answer_data": [ "Assertion timestamp at source", "Ingestion timestamp", "Timezone offset handling note" ] }, { "id": "q-prov-conflict", "text": "When two sources disagree about the same element, which precedence rule decides?", "kind": "decision", "answer_data": [ "Source precedence order", "Conflict record reference", "Adjudication rationale" ] }, { "id": "q-prov-confidence", "text": "What confidence or completeness qualifier attaches to a value obtained through a restricted or partial interface?", "kind": "quality", "answer_data": [ "Confidence qualifier", "Completeness note", "Interface permission scope" ] } ], "data_elements": [ { "id": "de-source-assertion", "name": "Source assertion", "description": "Source system, asserting party, assertion timestamp and ingestion timestamp for an element value.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002", "SRC-012" ] }, { "id": "de-source-precedence-rank", "name": "Source precedence rank", "description": "Rank used to resolve disagreement between sources reporting the same element.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Provenance is metadata attached to every asserted element rather than a separate document; the platform's own change log is the adopting Dimension's responsibility and is not an audit-trail model owned here." }, { "id": "supporting-evidence-linkage", "name": "Supporting evidence linkage", "description": "An index of the evidence that supports account assertions, holding references and evidence types rather than copies of documents owned by other models.", "source_refs": [ "SRC-003", "SRC-004", "SRC-010" ], "questions": [ { "id": "q-ev-which", "text": "Which evidence items support the identity, party and classification assertions on this account?", "kind": "evidence", "answer_data": [ "Evidence item reference", "Evidence type code", "Supported assertion reference" ] }, { "id": "q-ev-hold", "text": "Which model or system holds each evidence item, and how is it retrieved?", "kind": "relationship", "answer_data": [ "Holding system or model reference", "Retrieval method description", "Access precondition" ] }, { "id": "q-ev-valid", "text": "Until when does each evidence item remain valid, and what triggers refresh?", "kind": "temporal", "answer_data": [ "Evidence validity end date", "Refresh trigger list", "Last verification timestamp" ] }, { "id": "q-ev-sufficient", "text": "Is the evidence set sufficient under the applicable regime, and what is missing?", "kind": "validation", "answer_data": [ "Sufficiency assessment outcome", "Missing evidence list", "Assessing rule reference" ] } ], "data_elements": [ { "id": "de-evidence-index-entry", "name": "Evidence index entry", "description": "Reference, type, holding system and validity window for one supporting evidence item.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "de-evidence-sufficiency", "name": "Evidence sufficiency assessment", "description": "Outcome of the check that the evidence set satisfies the applicable regime, with any gaps listed.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "evidence-register", "name": "Account evidence register", "description": "Index of supporting evidence items for the account with references, types and validity windows; it holds pointers, not evidence content.", "media_or_form": [ "structured register", "tabular index" ], "serial": false, "identity_strategy": "Keyed by the account master identifier; a single current register instance per account with versioned revisions and no date used as the identifier.", "source_refs": [ "SRC-003", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "retention-and-disposition-schedule", "name": "Retention and disposition designation", "description": "How long each class of account context must be retained, when disposition falls due, and which policy owner executes deletion, which is outside this model.", "source_refs": [ "SRC-004", "SRC-005", "SRC-009", "SRC-010" ], "questions": [ { "id": "q-ret-period", "text": "What retention period applies to each class of account context, and which instrument sets it?", "kind": "retention", "answer_data": [ "Retention period duration per class", "Governing instrument reference", "Applicable jurisdiction" ] }, { "id": "q-ret-clock", "text": "From which event does the retention clock start: opening, last activity, closure or transfer?", "kind": "temporal", "answer_data": [ "Clock start event type", "Clock start timestamp", "Computed disposition due date" ] }, { "id": "q-ret-hold", "text": "Is any record under legal hold that suspends disposition?", "kind": "exception", "answer_data": [ "Legal hold flag", "Hold authority reference", "Hold review date" ] }, { "id": "q-ret-execute", "text": "Which policy owner executes disposition, and what tombstone remains after deletion?", "kind": "authority", "answer_data": [ "Executing policy owner reference", "Tombstone content specification", "Disposition decision record reference" ] } ], "data_elements": [ { "id": "de-retention-rule", "name": "Retention rule", "description": "Retention period, clock-start event and governing instrument for a class of account context.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-010" ] }, { "id": "de-disposition-due-date", "name": "Disposition due date", "description": "Computed date at which disposition of a record class falls due, absent a legal hold.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "retention-schedule", "name": "Account retention and disposition schedule", "description": "Schedule mapping account context classes to retention periods, clock-start events, holds and the responsible executing policy owner.", "media_or_form": [ "structured schedule", "policy table" ], "serial": false, "identity_strategy": "Keyed by adopting Dimension plus jurisdiction with an explicit version label; superseded versions are retained and never overwritten, and no date is used as the identifier.", "source_refs": [ "SRC-005", "SRC-009", "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "id": "quality-access-and-alignment", "name": "Validation, Access Designation and Standards Alignment", "description": "The controls that keep account context correct, the designation of who may see it, and the mappings that let it travel between representations.", "source_refs": [ "SRC-002", "SRC-008", "SRC-009", "SRC-012", "SRC-013", "SRC-014" ], "findings": [ { "id": "validation-and-quality-controls", "name": "Validation rules and quality measures", "description": "Structural and referential checks applied to account context, including identifier structure and check-digit validation, mandatory-field rules and cross-field consistency.", "source_refs": [ "SRC-002", "SRC-008", "SRC-013" ], "questions": [ { "id": "q-val-structure", "text": "Which structural and check-digit rules validate each identifier scheme value?", "kind": "validation", "answer_data": [ "Structural pattern per scheme", "Check-digit algorithm reference", "Validation outcome and timestamp" ] }, { "id": "q-val-mandatory", "text": "Which elements are mandatory for this account's classification and interface profile?", "kind": "requirement", "answer_data": [ "Mandatory element list per profile", "Profile identifier", "Conditional rule description" ] }, { "id": "q-val-cross", "text": "Which cross-field consistency rules must hold, for example between status, closure timestamp and dormancy designation?", "kind": "constraint", "answer_data": [ "Rule expression", "Rule severity", "Violation record reference" ] }, { "id": "q-val-measure", "text": "How are completeness and freshness of account context measured and reported?", "kind": "quality", "answer_data": [ "Completeness metric definition", "Freshness threshold", "Measurement run timestamp" ] } ], "data_elements": [ { "id": "de-validation-rule", "name": "Validation rule", "description": "Executable or declarative rule with scope, severity and the profile in which it applies.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-013" ] }, { "id": "de-validation-outcome", "name": "Validation outcome", "description": "Result of applying the rule set to an account record, with violations and run timestamp.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "validation-rule-set", "name": "Account validation rule set", "description": "Declared set of structural, mandatory-field and cross-field rules for account context, versioned by profile.", "media_or_form": [ "structured rule set", "specification document" ], "serial": false, "identity_strategy": "Keyed by profile name plus semantic version; a date is never used as the identifier and superseded versions remain resolvable.", "source_refs": [ "SRC-002", "SRC-008", "SRC-013" ] }, { "id": "validation-report", "name": "Validation run report", "description": "Report of a validation run against a population of account records, listing violations by severity.", "media_or_form": [ "structured report" ], "serial": true, "identity_strategy": "Named by rule set version plus population identifier plus a monotonic run sequence number, with the run timestamp carried as an attribute rather than as the identifier.", "source_refs": [ "SRC-002", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "data-access-and-sharing-designation", "name": "Access and sharing designation", "description": "Which classes of account context may be disclosed to which recipient categories under which permission scope, expressed as designation and consent reference only.", "source_refs": [ "SRC-002", "SRC-009", "SRC-014" ], "questions": [ { "id": "q-acc-classes", "text": "Which classes of account context are shareable, and which are restricted or maskable?", "kind": "access", "answer_data": [ "Context class list with sharing designation", "Masking requirement per class", "Designation basis reference" ] }, { "id": "q-acc-permission", "text": "Which permission scope must a requester hold to see detailed identification and servicer data rather than basic data?", "kind": "security", "answer_data": [ "Permission scope name", "Fields exposed per scope", "Interface profile reference" ] }, { "id": "q-acc-consent", "text": "Which authorisation record permits a third party to receive this account's data, and where is it held?", "kind": "relationship", "answer_data": [ "Authorisation record reference", "Holding model or system", "Authorisation validity window" ] }, { "id": "q-acc-obligation", "text": "Which regulatory access obligation is asserted for this account, and how settled is it?", "kind": "authority", "answer_data": [ "Obligation instrument reference", "Jurisdiction", "Settled or contested status with basis" ] } ], "data_elements": [ { "id": "de-sharing-designation", "name": "Sharing designation", "description": "Per class of account context, whether it may be disclosed, to which recipient categories and under what masking.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-009" ] }, { "id": "de-authorisation-reference", "name": "Authorisation reference", "description": "Pointer to the consent or authorisation record held by the authorisation model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Only the designation and a reference belong here; issuing, evaluating, revoking and logging authorisations are owned by the consent and authorisation model, and holding a consent artifact would claim those semantics." }, { "id": "standard-crosswalks-and-conflicts", "name": "Standards crosswalks and conflict register", "description": "Mappings from this model to external account representations and a register of the points where those representations conflict or cannot be satisfied simultaneously.", "source_refs": [ "SRC-001", "SRC-002", "SRC-009", "SRC-012", "SRC-013", "SRC-014" ], "questions": [ { "id": "q-map-target", "text": "To which external representations is this model mapped, and at which version of each?", "kind": "interoperability", "answer_data": [ "Target representation name", "Target version or release", "Mapping direction" ] }, { "id": "q-map-unmapped", "text": "Which elements have no counterpart in a target representation, and how is the loss recorded?", "kind": "quality", "answer_data": [ "Unmapped element list per target", "Loss handling rule", "Extension mechanism used" ] }, { "id": "q-map-conflict", "text": "Where do two aligned standards impose incompatible cardinality or semantics on the same element?", "kind": "constraint", "answer_data": [ "Conflicting standards pair", "Conflicting element and nature of conflict", "Selected resolution and rationale" ] }, { "id": "q-map-claim", "text": "What evidence supports any conformance claim, and where is a claim explicitly withheld?", "kind": "evidence", "answer_data": [ "Conformance evidence reference", "Claim scope", "Explicit non-claim statement" ] } ], "data_elements": [ { "id": "de-crosswalk-entry", "name": "Crosswalk entry", "description": "Mapping from a local element to a target representation element with version and transformation note.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-012" ] }, { "id": "de-conflict-entry", "name": "Conflict entry", "description": "Record of an incompatibility between aligned standards with the chosen resolution and its rationale.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-014" ] } ], "artifacts": [ { "id": "standards-crosswalk", "name": "Standards crosswalk table", "description": "Element-level mapping between this model and external account representations such as ISO 20022 account components, the Open Banking account resource and FIBO account classes.", "media_or_form": [ "mapping table", "structured crosswalk record" ], "serial": false, "identity_strategy": "Keyed by target representation name plus target version plus crosswalk semantic version; no date component is used in the identifier.", "source_refs": [ "SRC-001", "SRC-002", "SRC-012", "SRC-013" ] }, { "id": "alignment-conflict-register", "name": "Alignment conflict register", "description": "Register of conflicts between aligned standards and regimes, the resolution chosen and the claims deliberately withheld.", "media_or_form": [ "structured register" ], "serial": false, "identity_strategy": "Single current register per model version, identified by model identifier plus register version; superseded versions remain resolvable.", "source_refs": [ "SRC-009", "SRC-013", "SRC-014" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "register-account-record", "name": "Register account record", "description": "Create the model's context record for an account by binding its authoritative master-system identifier, servicer reference and opening timestamp.", "inputs": [ "Master-system account identifier", "Servicer reference", "Opening event timestamp and observation timestamp" ], "outputs": [ "Account context record with resolved identity", "Identity precedence decision" ], "preconditions": [ "The master-system identifier is unique within the servicer namespace", "The servicer is identified by a governed identifier scheme" ], "effects": [ "Creates a context record in this model only", "Does not open, authorise or activate the account in any servicing system" ], "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "resolve-identifier-set", "name": "Resolve and normalise the identifier set", "description": "Normalise, structurally validate and rank the scheme-qualified identifiers that denote the account, including check-digit verification where the scheme defines one.", "inputs": [ "Scheme-qualified identifier candidates", "Scheme structure and check-digit rules" ], "outputs": [ "Normalised identifier set with precedence", "Validation outcome per identifier" ], "preconditions": [ "Each candidate declares its scheme and scheme owner" ], "effects": [ "Records validation outcomes without altering the source identifier", "Flags identifiers that fail structural validation rather than discarding them" ], "source_refs": [ "SRC-008", "SRC-013", "SRC-002" ] }, { "id": "classify-account", "name": "Assign account classifications", "description": "Attach product, regulatory and tax classifications to the account, each carrying its code set, version, jurisdiction and effective period.", "inputs": [ "Product code set values", "Regulatory category assertions", "Tax regime category assertion" ], "outputs": [ "Classification set with effective periods", "Unclassifiable exception record" ], "preconditions": [ "Each code set version is resolvable", "Jurisdiction is known for regulatory and tax categories" ], "effects": [ "Adds time-bounded classification entries", "Does not reinterpret or redefine any external code set" ], "source_refs": [ "SRC-002", "SRC-003", "SRC-010", "SRC-011" ] }, { "id": "bind-account-parties", "name": "Bind party roles to the account", "description": "Attach holder, beneficial owner, controlling person and mandate-holder role bindings as references to externally governed party identifiers.", "inputs": [ "Party identifier references", "Role type and scope", "Role validity window" ], "outputs": [ "Party role binding set", "Unresolved party reference exception" ], "preconditions": [ "Party identifiers resolve in the referenced party model or registry" ], "effects": [ "Records role bindings and their validity windows", "Does not create, verify or amend party master records" ], "source_refs": [ "SRC-001", "SRC-006", "SRC-010" ] }, { "id": "declare-denomination-reference", "name": "Declare denomination reference", "description": "Attach the account's denomination and permitted instrument references to the monetary unit or instrument model.", "inputs": [ "Monetary unit or instrument reference", "Permitted instrument class list" ], "outputs": [ "Denomination reference binding", "Multi-denomination indicator" ], "preconditions": [ "The referenced unit or instrument entry resolves in the target model" ], "effects": [ "Records a reference only", "Does not define unit codes, minor units, conversion or instrument behaviour" ], "source_refs": [ "SRC-002", "SRC-011" ] }, { "id": "record-state-transition", "name": "Record account state transition", "description": "Record a change in account status with its event timestamp, observation timestamp, cause reference and resulting capability effects.", "inputs": [ "New status value and code set", "Event timestamp", "Observation timestamp and source reference" ], "outputs": [ "State transition record", "Rejected transition exception" ], "preconditions": [ "The transition is permitted by the declared status model", "Event and observation timestamps are both supplied" ], "effects": [ "Appends an immutable transition record", "Does not execute the underlying banking operation that caused the change" ], "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "derive-dormancy-candidacy", "name": "Derive dormancy candidacy", "description": "Apply the jurisdictional inactivity test to the last holder-initiated activity timestamp and produce a dormancy determination with its basis and exceptions.", "inputs": [ "Last holder-initiated activity timestamp", "Applicable inactivity period and exceptions", "Account terms affecting withdrawal" ], "outputs": [ "Dormancy determination with basis", "Exception record where an exception blocks dormancy" ], "preconditions": [ "The applicable jurisdictional test is known", "Activity signals have a stated source and observation time" ], "effects": [ "Sets a designation on this model's record", "Does not transfer balances, notify holders or discharge any statutory obligation" ], "source_refs": [ "SRC-005" ] }, { "id": "bind-posting-container", "name": "Bind the posting container", "description": "Register the reference and selection key by which the account's contained postings are located in the posting model.", "inputs": [ "Contained posting model reference", "Selection key definition", "Partition dimensions where used" ], "outputs": [ "Posting container binding", "Discrepancy record where a declared balance and the contained set disagree" ], "preconditions": [ "The selection key is stable across the account lifetime" ], "effects": [ "Records the binding and any observed discrepancy", "Never creates, amends, reverses or interprets a posting" ], "source_refs": [ "SRC-001", "SRC-012" ] }, { "id": "assemble-account-context-package", "name": "Assemble the account context package", "description": "Produce the agent-readable package for one account, comprising the bootstrap file, the bundle and layer structure and the resolvable artifact references.", "inputs": [ "Account context record", "Access designation and requester scope", "Artifact references" ], "outputs": [ "Context package with bootstrap contract", "Omission list for withheld classes" ], "preconditions": [ "Access designation for the requester scope is determined", "Every included artifact reference resolves" ], "effects": [ "Emits a package that states what was withheld and why", "Does not evaluate or grant authorisation itself" ], "source_refs": [ "SRC-002", "SRC-009" ] }, { "id": "project-to-interchange-profile", "name": "Project to an interchange profile", "description": "Map the account context onto an external representation and report the elements that cannot be carried by that representation.", "inputs": [ "Target representation name and version", "Crosswalk table", "Account context record" ], "outputs": [ "Projected representation", "Unmapped element report" ], "preconditions": [ "A crosswalk exists for the target version" ], "effects": [ "Produces a projection without asserting conformance", "Records loss explicitly instead of silently dropping elements" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-012", "SRC-013" ] }, { "id": "schedule-retention-disposition", "name": "Schedule retention disposition", "description": "Compute disposition due dates from the retention schedule and emit a disposition decision record for the adopting Dimension to execute.", "inputs": [ "Retention rules with clock-start events", "Account lifecycle timestamps", "Legal hold flags" ], "outputs": [ "Disposition decision record", "Suspended disposition record where a hold applies" ], "preconditions": [ "Applicable jurisdiction and retention instrument are known", "Clock-start event timestamps are present" ], "effects": [ "Emits a decision and a tombstone specification", "Does not delete records; execution belongs to the adopting Dimension's policy owner" ], "source_refs": [ "SRC-005", "SRC-009", "SRC-010" ] } ], "composition": [ { "target": "WM-ECO-004", "relation": "REFERENCE", "purpose": "The account declares its denomination and permitted monetary instruments by reference; identity, parties, lifecycle and rules stay with this model and unit or instrument semantics stay with the target.", "required": true, "source_refs": [ "SRC-002", "SRC-011" ] }, { "target": "WM-ECO-016", "relation": "CHILD", "purpose": "The account is the container for its postings and supplies the container binding and selection key; posting creation, amendment, reversal and balance derivation are owned by the target.", "required": true, "source_refs": [ "SRC-001", "SRC-012" ] }, { "target": "WM-XCT-014", "relation": "COMPOSE", "purpose": "This model composes into the registered parent container; cross-account exchange semantics and orchestration remain with the parent.", "required": true, "source_refs": [ "SRC-001" ] }, { "target": "Party and legal-entity identity model (candidate sibling, not yet registered)", "relation": "REFERENCE", "purpose": "Holder, beneficial owner, controlling person, servicer and mandate-holder bindings resolve to externally governed party identifiers such as the LEI; party master data and verification stay with the sibling.", "required": true, "source_refs": [ "SRC-006", "SRC-010" ] }, { "target": "Consent and data-access authorisation model (candidate sibling, not yet registered)", "relation": "REFERENCE", "purpose": "The account carries a sharing designation and an authorisation reference only; issuance, runtime evaluation, revocation and access logging belong to the sibling.", "required": false, "source_refs": [ "SRC-002", "SRC-009", "SRC-014" ] }, { "target": "Payment instruction and credit transfer model (candidate sibling, not yet registered)", "relation": "REFERENCE", "purpose": "The account is referenced as debtor or creditor account by payment instructions; instruction lifecycle, reachability, clearing and settlement stay with the sibling.", "required": false, "source_refs": [ "SRC-008", "SRC-012" ] }, { "target": "Deposit guarantee or deposit insurance scheme model (candidate sibling, not yet registered)", "relation": "REFERENCE", "purpose": "The account carries scheme designation, eligibility status and ownership category; coverage computation, aggregation across accounts and payout stay with the scheme.", "required": false, "source_refs": [ "SRC-004", "SRC-007" ] }, { "target": "ISO 20022 account and account-management business components (acmt, camt)", "relation": "ALIGN", "purpose": "Align account identification, type, servicer, opening, mandate maintenance, switching, closing and account reporting concepts with the ISO 20022 repository without claiming conformance.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "ISO 13616 IBAN structure and national IBAN format registry", "relation": "ALIGN", "purpose": "Align the IBAN identifier scheme, its structure and its check-digit validation with the ISO standard and the registry maintained by its Registration Authority.", "required": false, "source_refs": [ "SRC-008", "SRC-013" ] }, { "target": "FIBO FBC ClientsAndAccounts ontology", "relation": "ALIGN", "purpose": "Align the account, account holder, account provider, account identifier, deposit account, loan or credit account and ledger account concepts with the published ontology definitions.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "Open Banking Read/Write API v4.0 account resource", "relation": "ALIGN", "purpose": "Align the account resource projection, identification scheme choices, status and permission-scoped field visibility with a deployed interface specification.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "CRS and FATCA financial account categories", "relation": "ALIGN", "purpose": "Align the tax classification of the account with the depository, custodial, equity or debt interest, cash value insurance and annuity categories and their excluded-account carve-outs.", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "A Dimension adopting this model must name a single accountable owner for account context, which is the contracting party, the financial institution servicing the account or the supervising regulator, and record the basis of that ownership.", "The owner package must declare the jurisdictions in force for the account population, because classification, protection, dormancy, retention and access obligations are all jurisdiction-bound rather than universal.", "The owner package must declare, for every outgoing reference, which target model or external party owns execution, including monetary unit semantics, posting lifecycle, authorisation evaluation, guarantee payout and record deletion.", "The owner package must state which external code sets and their versions are in force, and must not fork or extend a code set locally without registering the extension as a named local profile." ], "namespace_guidance": "Use one namespace per adopting Dimension and per servicing institution, so that a servicer-proprietary account identifier is only ever unique inside its servicer namespace. Governed global identifiers such as an IBAN or an LEI keep the namespace of their issuing authority and are never re-minted locally. Local model identifiers stay lower-kebab-case, carry no date component and never encode a jurisdiction, product or status that can change.", "registry_links": [ "Vercy registry entry vr.wm-eco-015 with parent WM-XCT-014 and contained WM-ECO-016", "ISO 13616 national IBAN format registry maintained by the standard's Registration Authority", "Global LEI Index for legal-entity references used in holder, servicer and control-chain bindings", "ISO 20022 message definition catalogue for account management and account reporting projections" ] }, "canon_and_patch": { "canonicalization_rules": [ "Canonical form is the format-neutral element graph defined by this model; JSON, YAML, Markdown, HTML, Git, MCP and MongoDB projections are renderings and never the source of truth.", "Identifier values are canonicalised by removing presentation separators and applying the scheme's own normalisation, while the original presentation form is retained as a separate display value.", "All time values are canonicalised to RFC 3339 with seconds and an explicit offset; local-time strings without an offset are rejected rather than assumed to be UTC.", "Amounts are canonicalised as a decimal value plus a denomination reference; a currency symbol or code embedded in a text field is never treated as the denomination.", "Coded values are canonicalised as a triple of code set name, code set version and code value, so that an unqualified bare code is treated as incomplete." ], "patch_rules": [ "Patches are element-scoped and must carry the asserting source, the assertion timestamp and the ingestion timestamp; a patch that cannot state its source is rejected.", "Status, classification, party binding and terms changes are appended as new time-bounded entries; existing entries are closed with an effective-to timestamp rather than overwritten.", "A patch may not create, amend or delete a contained posting, alter a monetary unit definition, or change an authorisation record; such a patch is rejected and routed to the owning model.", "Identifier corrections are modelled as supersession with both values retained and the superseded value marked, because downstream references may still resolve against it.", "Conflicting concurrent patches are resolved by declared source precedence, and the losing assertion is retained as a conflict entry rather than discarded." ], "compatibility_rules": [ "Adding an optional element, a new code set alignment or a new artifact type is a minor change; removing an element, tightening cardinality or changing an identity rule is a breaking change.", "A projection to an external representation may be revised independently of the model, provided the crosswalk records the target version it was built against.", "Deprecated elements remain resolvable for at least one full major version and are marked with their replacement.", "Conformance to an external standard is never asserted by version bump alone; a claim requires evidence recorded in the conflict register and the crosswalk." ] }, "artifact_rules": { "identity_priority": [ "The authoritative master-system identifier assigned by the system of record, which for a financial account is the servicing institution's account identifier and for an artifact is the identifier assigned by the system that produced it.", "A governed global identifier or IRI issued by a recognised authority, such as an IBAN under ISO 13616 for the account or an LEI under ISO 17442 for a legal entity, used when no master-system identifier is available or when cross-institution resolution is required.", "A UUID or ULID assigned by the adopting Dimension, used only when neither of the above exists, and always recorded as Dimension-assigned rather than presented as authoritative.", "A date, a period, a status, a balance or a party name is never an identifier; where a natural key seems to exist it is recorded as an attribute and a surrogate identifier is minted instead." ], "timestamp_rule": "All time values use RFC 3339 date-time with explicit seconds and an explicit numeric UTC offset or the literal Z; local times without an offset are rejected. Event time and observation or ingestion time are recorded as separate fields whenever they can differ, which for this model includes status transitions, balance observations, opening and closure, dormancy determination and every ingested source assertion. Dates that are genuinely date-only, such as a disposition due date, are recorded as full-date values and are never coerced into an instant with an assumed offset.", "serial_naming_rule": "Serial artifacts, namely the statement of fees, the account statement and the validation run report, are named by their subject identifier plus the reporting period start and end plus a monotonic sequence number within that subject. The issue timestamp is carried as an attribute and never used as the identifier, and a regenerated instance for the same period increments the sequence and links to the instance it supersedes.", "integrity_rule": "Every artifact instance carries a content digest computed over its canonical serialisation, the algorithm name, the digest computation timestamp and the reference to the source system that produced the content. A stored artifact whose recomputed digest differs from the recorded digest is marked as integrity-failed and quarantined rather than silently replaced, and the failure is recorded as a quality finding against the account record." }, "policies": [ "Account context is asserted, not owned in duplicate: where an element is governed by a referenced or contained model, this model stores a reference and the reference resolution metadata, never a shadow copy that could drift.", "No conformance to any external standard or regulation is claimed without recorded evidence; where an obligation is contested, under reconsideration or jurisdiction-specific, the model records the status as unsettled instead of asserting compliance.", "Sensitive identifiers, including full account numbers and primary account numbers, are masked by default in any projection whose requester scope does not carry the detailed-identification permission.", "Deletion, restriction enforcement, authorisation evaluation and guarantee payout are never performed by this model; it emits decisions and designations and names the executing owner.", "Every classification, status, term, protection designation and party binding carries an effective period, because all of them are known to change over the life of an account." ], "crud": { "read": [ "Reads are scoped by requester permission: a basic scope exposes classification, currency reference, status and nickname, while a detailed scope is required for full identification, servicer detail and statement designation.", "A read must return the provenance of each element, including source system, assertion timestamp and ingestion timestamp, so that an agent can judge freshness.", "A read that withholds a class of context must state that a withholding occurred and on what designation, rather than returning a silently truncated record.", "Reads of contained posting data are not served by this model; the caller is redirected to the contained posting model using the registered container binding." ], "create": [ "Creation requires an authoritative master-system identifier and a servicer reference; a record cannot be created keyed only on a governed global identifier such as an IBAN, because that identifier may be reassigned by the servicer.", "Creation requires an opening event timestamp and an observation timestamp, both in RFC 3339 with an explicit offset.", "Creation must record at least one classification with its code set and version, and at least one holder role binding referencing an external party identifier.", "Creating an account context record never opens an account in a servicing system and must not be represented to an agent as having done so." ], "update": [ "Updates are append-only for status, classification, party binding, terms, limits, protection designation and balance observation; the prior entry is closed with an effective-to timestamp.", "An update that changes an identifier is recorded as supersession, retaining the superseded value and marking it, so stale external references remain diagnosable.", "An update may not modify a referenced model's data, including monetary unit definitions, party master records, authorisation records or contained postings.", "Every update records the asserting source and both event and ingestion timestamps; an update without a source is rejected." ], "delete": [ "This model's own account context records are retained for the period computed by the retention schedule from the declared clock-start event, which is typically account closure, last holder-initiated activity or balance transfer, whichever the governing instrument names.", "Deletion is soft by default: the record is closed and replaced by a tombstone carrying the master-system identifier, the account status at closure, the disposition decision reference, the retention instrument reference and the disposition timestamp, so that inbound references resolve to an explicit disposed state rather than to nothing.", "Hard deletion is only performed on a disposition decision emitted by this model and executed by the adopting Dimension's policy owner named in the retention schedule; this model never executes deletion and never asserts that deletion has occurred without an execution confirmation reference.", "Deletion of contained postings is out of this model's boundary and is owned by WM-ECO-016; deletion or minimisation of party master data is owned by the party model; deletion of authorisation records is owned by the consent and authorisation model; a disposition decision here must not be read as authority over any of them.", "A record under legal hold or under an unresolved dormancy or reclaim obligation is not disposed of; the disposition is suspended, the suspending authority is recorded and a review date is set." ] }, "roles": [ { "name": "Account context owner", "responsibilities": [ "Accountable for the correctness and currency of account identity, classification, party bindings, terms and status within the adopting Dimension", "Approves source precedence rules and resolves conflicting assertions about the same account" ] }, { "name": "Standards and alignment steward", "responsibilities": [ "Maintains crosswalks to external representations and the versions they target", "Maintains the alignment conflict register and refuses conformance claims that lack recorded evidence" ] }, { "name": "Regulatory and jurisdiction steward", "responsibilities": [ "Declares the jurisdictions in force and maps classification, protection, dormancy, access and retention obligations onto them", "Records obligations that are contested or under reconsideration as unsettled rather than as compliance facts" ] }, { "name": "Boundary and composition reviewer", "responsibilities": [ "Checks that no bundle, layer, finding or function reproduces a referenced or contained model's lifecycle, evaluation, execution, enforcement or audit-trail semantics", "Routes any locally modelled target-owned concept to a composition link, out-of-scope entry or boundary note" ] }, { "name": "Data quality and validation operator", "responsibilities": [ "Runs the validation rule set against the account population and publishes validation run reports", "Raises integrity failures and completeness gaps as quality findings rather than correcting source data silently" ] }, { "name": "Retention and disposition policy owner", "responsibilities": [ "Maintains the retention schedule and legal holds and executes disposition decisions emitted by this model", "Confirms execution back to the model so tombstones carry an execution reference" ] } ], "access": { "default_rule": "Deny by default. Account context is released only to a requester whose declared scope and purpose match a recorded sharing designation, and identifiers that can be used to initiate movement of funds are masked unless the requester holds the detailed-identification scope. The model expresses this designation only; the decision to admit a requester is made and logged by the authorisation model.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "A supervisory, tax or law-enforcement authority acting under a recorded legal basis may receive context that is otherwise withheld, with the instrument reference recorded against the disclosure designation.", "A restriction or freeze may itself be non-disclosable to the account holder where the imposing authority prohibits tipping off; the designation records that the reason is withheld rather than that no reason exists.", "A deposit guarantee scheme may receive holder, ownership category and balance designation for eligible accounts under its statutory basis, without receiving the full account context package.", "A receiving provider in a switching case receives only the arrangements, balances and redirection items in scope of the holder's switch authorisation.", "An emergency continuity read may bypass the normal scope check when a servicer is in resolution, provided the bypass is recorded with its authorising party and reviewed afterwards." ], "audit_requirements": [ "The adopting Dimension's platform must record, for every release of account context, the requester identity, the scope granted, the designation relied on and the timestamp; this model specifies the requirement and does not define or own the audit-trail record model.", "Every disclosure made under an exception must carry the instrument or authority reference that permitted it.", "Withheld classes must be enumerated in the response so that an agent can distinguish absent data from withheld data.", "Integrity failures, source conflicts and validation violations must be retained for at least the retention period of the account context they concern." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID and registry ID", "Composition links with relation type and the owner of execution for each", "Jurisdictions in force and unsettled obligations", "Access default rule and the scopes that gate each context class" ], "read_order": [ "AGENTS.md first, to obtain the model identity, the storage and interface bindings and the composition links before any data is fetched", "The scope statement, out-of-scope list and boundary notes, to learn which questions this model must not answer", "The bundle and layer index, to select the relevant findings without loading the whole model", "The specific findings and their questions, then only the artifacts those findings declare", "The coverage record last, to read known omissions, conflicts and regional assumptions before acting on any answer" ] } }, "coverage": { "claim": "Audited single-provider draft for WM-ECO-015 Financial Account. The aggregate root, the \"entity\" entry kind, the CONTAINS binding to WM-ECO-016 and the REFERENCE to WM-ECO-004 hold against the frozen registry record and relationship contract, and the 26 findings across 6 bundles and 14 layers do cover identity, identifier schemes, classification, holders and authority, denomination reference, terms and limits, protection designation, state and lifecycle, position declaration, provenance, evidence, retention, access designation and standards alignment. Coverage is partial and jurisdiction-skewed and is not claimed for any single jurisdiction, no conformance is claimed, and the security, privacy, access, retention and interoperability checklist entries over-claim relative to the questions that actually carry them and must be downgraded to partial before publication. Account-group, umbrella and notional-pooling aggregation, United States unclaimed-property periods, verified FATF and FinCEN beneficial-ownership thresholds, and element-level ISO 20022 and ISO 13616 normative text remain outside the verified set. No independent second-provider review exists; the result is a reviewable draft only.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Master-system identifier first, then governed global identifiers such as IBAN and LEI, then Dimension-assigned ULID; supersession retained and dates explicitly excluded as identifiers." }, { "dimension": "lifecycle", "status": "covered", "notes": "Opening, status transitions, restriction, closure, switching and dormancy are modelled with permitted transitions and separate event and observation timestamps." }, { "dimension": "relationships", "status": "covered", "notes": "Party role bindings, servicer relationship, denomination reference, posting container binding and sibling-model references are all typed and directional." }, { "dimension": "temporal", "status": "covered", "notes": "Every classification, binding, term, restriction and balance carries an effective period; RFC 3339 with seconds and an explicit offset is mandated and event time is separated from ingestion time." }, { "dimension": "provenance", "status": "covered", "notes": "Source system, asserting party, assertion timestamp, ingestion timestamp and source precedence are required on every asserted element, with conflicts retained rather than discarded." }, { "dimension": "ownership", "status": "covered", "notes": "Holder set with primary and secondary roles, ownership form, declared shares, beneficial owners and controlling persons, all as references to an external party model." }, { "dimension": "validation", "status": "covered", "notes": "Structural and check-digit validation for identifier schemes, mandatory-field rules per profile, cross-field consistency rules and completeness and freshness measures with versioned rule sets." }, { "dimension": "access", "status": "covered", "notes": "Deny by default with scope-gated release at bundle, layer, finding and artifact level, masking of fund-movement identifiers, and enumerated exceptions; evaluation and logging are delegated." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention schedule with clock-start events and legal holds, tombstone specification, and an explicit statement that execution belongs to the adopting Dimension's policy owner and that contained postings, party data and authorisations are deleted by their own models." }, { "dimension": "interoperability", "status": "covered", "notes": "Crosswalks to ISO 20022 account components, the Open Banking account resource, FIBO account classes, ISO 13616 and CRS categories, with unmapped elements and conflicts recorded and conformance withheld." }, { "dimension": "classification", "status": "covered", "notes": "Product, regulatory and tax classifications are separated, each with code set, version, jurisdiction and effective period, because they are set by different authorities." }, { "dimension": "authority", "status": "covered", "notes": "Mandates, signature combination rules, restriction authorities, regulatory grounds for refusal and termination, and named executing owners for every delegated action." }, { "dimension": "evidence and quality", "status": "covered", "notes": "Evidence register holds references not content, sufficiency assessments are recorded, and validation run reports are serial artifacts with digests." }, { "dimension": "measurement", "status": "covered", "notes": "Balances are typed observations with as-of and observation instants and a stated derivation owner; fee and limit values carry units and measurement windows." }, { "dimension": "spatial and jurisdiction", "status": "covered", "notes": "Booking jurisdiction, branch location and per-jurisdiction regulatory, protection, dormancy and retention designations; no geographic coordinate modelling is needed for this subject." }, { "dimension": "process and events", "status": "covered", "notes": "Opening, closure, switching, restriction, dormancy determination and disposition are modelled as events with causes and timestamps, without absorbing the execution of any of them." }, { "dimension": "security", "status": "covered", "notes": "Permission-scoped field visibility, masking rules, integrity digests with quarantine on mismatch, and a prohibition on shadow copies of governed data." }, { "dimension": "privacy", "status": "covered", "notes": "Masking defaults, non-disclosable restriction reasons, evidence held by reference, and minimisation delegated to the models that own the underlying personal data." }, { "dimension": "exception handling", "status": "covered", "notes": "Excluded tax accounts, dormancy exceptions, temporary high balances, legal holds, refused openings and emergency continuity reads are each modelled explicitly." }, { "dimension": "account aggregation across institutions", "status": "gap", "notes": "Grouping of one holder's accounts across institutions, relationship or umbrella account structures and pooled or notional cash-management structures are not modelled and no primary source was secured for them." } ], "known_omissions": [ "FATF Recommendations 10 and 11 and the FinCEN customer due diligence rule at 31 CFR 1010.230 could not be retrieved live because the publishers blocked automated access, so the beneficial ownership threshold, the control prong and the five-year record-keeping rule are represented only through HMRC and EU proxies and are marked as unverified detail.", "The ISO 20022 e-Repository page for the CashAccount business component and the ISO 13616 IBAN Registry file did not render for this research, so element-level ISO 20022 and IBAN detail is grounded in the Bundesbank and Open Banking renderings and treated as alignment rather than verified normative text.", "United States state unclaimed-property dormancy periods and the Revised Uniform Unclaimed Property Act could not be verified, so only the United Kingdom fifteen-year statutory test is cited and dormancy is treated as jurisdictional.", "Securities and custody account internal structure, including position holdings, safekeeping accounts and segregation of client assets, is only classified, not decomposed.", "Islamic and profit-sharing account structures, notional pooling, virtual account hierarchies and escrow or client-money segregation rules are under-modelled and no primary source was secured.", "Tokenised deposit and account-based digital currency identifier schemes are acknowledged only through the CRS depository-account expansion and are otherwise not modelled.", "Payment card account specifics beyond a masked primary account number as an identifier scheme are not modelled." ], "conflicts": [ "Deposit protection algebra differs by regime: the United States applies a per-depositor, per-insured-bank, per-ownership-category limit of USD 250 000, while the European Union applies EUR 100 000 per depositor per credit institution with per-depositor treatment of joint accounts. A single insured indicator is therefore unsafe and the model carries scheme-scoped designations only.", "The United States account-data-sharing obligation is unsettled: the Personal Financial Data Rights rule was issued in October 2024, but the Bureau opened a reconsideration by advance notice in August 2025. Conformance must not be asserted, and the access designation records the obligation status as contested.", "Denomination cardinality conflicts across projections: the Open Banking v4.0 resource makes currency mandatory except for switched accounts, while ontology and message-standard views permit multi-denomination and non-currency-denominated ledger accounts. The model keeps denomination as a zero-to-many reference and records the conflict per projection.", "Tax classification is time-versioned: the depository account definition expands on 1 January 2026 to specified electronic money products and central bank digital currencies, so a classification field without an effective period would misstate history.", "No normative global account status code list was found. Interface enumerations such as enabled and disabled do not align with core-banking states such as dormant, blocked and escheated, so status is carried as a scheme-qualified code rather than as a canonical enumeration.", "Dormancy thresholds conflict across jurisdictions, with a fifteen-year statutory test in the United Kingdom against materially shorter periods elsewhere, so dormancy cannot be expressed as a global constant." ], "regional_assumptions": [ "IBAN-first identification is assumed only for the European Economic Area and other adopting countries; United States accounts are identified by routing number plus account number and many jurisdictions use a domestic basic bank account number alone.", "The payment account, basic-features account, fee information document, statement of fees and switching-service constructs are assumed only for European Union and European Economic Area consumer payment accounts.", "Deposit guarantee constructs follow the European Union directive for European accounts and the Federal Deposit Insurance Corporation framework for United States insured depository institutions; other jurisdictions operate different schemes not modelled here.", "HMRC manual pages are used as an accessible rendering of the Common Reporting Standard; implementing legislation and excluded-account lists vary by jurisdiction.", "The fifteen-year dormancy test and the reclaim-fund mechanism are United Kingdom specific and are not assumed elsewhere.", "The Open Banking Read/Write API v4.0 projection reflects the United Kingdom ecosystem; other open-finance frameworks expose different account resources and permission models." ], "adversarial_checks": [ "Tested whether balance computation belongs here. Rejected: balances are declared observations with a type, a denomination reference and an as-of instant, and derivation from entries is left to the contained posting model, with mismatches recorded as discrepancies rather than corrected locally.", "Tested whether currency, minor units or conversion belong here. Rejected: denomination is a pure outbound reference, and the reference finding carries no unit semantics at all.", "Tested whether consent evaluation, enforcement of restrictions or an access audit trail belong here. Rejected: the model carries designations and references, states the requirement that the platform log disclosures, and explicitly disclaims ownership of the audit-trail record model.", "Tested whether account and product or contract are separable. Kept separate: the account is the identified container and the terms are a bound instance referencing an external product model, because the same product yields many accounts with divergent bound terms.", "Searched for a normative global account status enumeration and for a normative global account type list. None found; recorded as a conflict and a gap rather than inventing a canonical list.", "Tested whether opening date plus branch could serve as a natural key. Rejected under the identity priority rule: a date is never an identifier, and both values are carried as attributes with a surrogate identifier minted where no master-system identifier exists.", "Tested whether an insured amount should be stored on the account. Rejected: coverage depends on aggregation across a depositor's accounts and is computed by the scheme, so only eligibility and ownership category are designated.", "Re-read every bundle, layer, finding and function against the two registered relation rationales. The denomination finding was reduced to a reference-only finding with an inline rationale, and the posting finding was reduced to a container binding that explicitly forbids creating, amending or interpreting postings." ] }, "researchAdjudication": { "providerMode": "single-provider-waiver", "activeProviders": [ "claude" ], "waivedProviders": [ "grok" ], "providerPolicy": { "contract_version": "1.0.0", "mode": "single-provider-waiver", "effective_at": "2026-08-29T09:06:27Z", "scope": "Queued subject-model research from WM-XCT-013 onward", "active_providers": [ "claude" ], "waived_providers": [ { "provider": "grok", "authorized_by": "repository owner", "authorized_at": "2026-08-29T09:06:27Z", "reason": "The repository owner explicitly instructed the research queue to continue without Grok after repeated structured-output failures." } ], "review_rule": "Claude-only results require a separate no-tools adversarial audit and remain reviewable drafts with a visible single-provider hold." }, "boundaryDecision": { "entry_kind": "entity", "status": "accepted", "rationale": "A financial account is an identified, durable container whose identity survives changes to every one of its attributes: holders are added and removed (q-hold-change), classification is re-versioned (q-class-effective), status transitions to terminal states (q-st-transitions) and the identifier itself may or may not survive a switch (q-sw-identifier). Identity independent of attribute values is the entity test, so the account is not a value, not an event and not a reified relationship, even though FIBO models it under client-and-account arrangements. The competing reading, that the true root is the holder-institution arrangement or the relationship or umbrella account above it, is rejected for this model and deferred to a separate account-group model rather than absorbed here, because absorbing it would make the aggregate root variable across jurisdictions and pooling structures. The registry entry_kind value standalone-mm and the research entry_kind value entity are two different vocabularies on two different planes (registry record plane versus subject model plane) and must not be reconciled by overwriting either field; the synthesizer should carry both and stop treating the registry review_state boundary-review-required as unresolved on the entry-kind axis alone. No split or merge is warranted: the account and its bound terms were correctly tested and kept separate, and the CONTAINS edge to WM-ECO-016 keeps posting semantics out." }, "decisions": [ { "concept": "Aggregate root: Financial Account as the container root of WM-ECO-015", "disposition": "accepted", "rationale": "The root is the identified container, not the arrangement and not the ledger. Every finding either identifies the container, binds a party or term to it, records a state of it, or declares a position over it; none of the 26 findings requires a different root to be coherent. The two registered relations resolve the only two places where a rival root could form." }, { "concept": "Account-group, umbrella, relationship and notional-pooling aggregation (declared checklist gap)", "disposition": "rejected for this model; deferred to a separate model candidate", "rationale": "Pooled and umbrella structures imply an aggregate above the account, which is exactly the pressure that would destabilise this aggregate root. The declared gap admits no primary source was secured. Absorbing it now would widen the root without evidence; registering it as a sibling candidate resolves the gap without scope creep." }, { "concept": "CONTAINS binding to WM-ECO-016 and the posting-container-binding finding", "disposition": "accepted", "rationale": "The finding carries only a selection key, a read boundary, a partition question and a discrepancy rule, holds no artifact, and its inline_only_rationale explicitly forbids reproducing posting records. This satisfies the ledger matryoshka contract and keeps balance derivation with the contained model." }, { "concept": "The serial account-statement artifact under balance-and-statement-declaration", "disposition": "reclassified: retain the statement issuance and delivery designation, move statement content ownership to WM-ECO-016", "rationale": "An account statement is a rendering over contained postings, so a serial artifact with media 'statement document' contradicts both the posting-container-binding rationale that forbids holding posting records here and the out_of_scope exclusion of statement rendering. The designation of period, frequency and recipient stays; the rendered instance does not." }, { "concept": "REFERENCE to WM-ECO-004 as denomination-only", "disposition": "accepted", "rationale": "The denomination finding carries four questions that are all reference-shaped and an inline_only_rationale that refuses unit codes, minor units and instrument behaviour. No monetary-unit semantics leaked into the pricing, limits or balance findings on inspection." }, { "concept": "Seven neighbour boundary notes with no registered relation row (party master, consent, payment instruction, product catalogue, deposit guarantee scheme, unclaimed property, and the WM-XCT-014 parent)", "disposition": "deferred: keep as prose boundary notes in the draft; do not mint typed edges", "rationale": "The frozen contract registers only two outbound relations. The boundary notes describe real instance-level references, but publishing them as typed edges without rows in the relations file would create dangling contract state. The parent edge may exist as an inbound row from WM-XCT-014 and must be confirmed, not assumed." }, { "concept": "Coverage checklist statuses for security, privacy, access, retention and interoperability", "disposition": "reclassified from covered to partial", "rationale": "The checklist asserts integrity digests with quarantine on mismatch and a prohibition on shadow copies, but no finding or question carries either. Security has one question, access one, retention one, privacy two. Interoperability claims ISO 20022 component crosswalks that the known omissions admit were never retrieved. The claims exceed their carriers." }, { "concept": "Coverage claim wording: 'eleven independent authorities' against 14 registered sources", "disposition": "accepted as reconcilable; wording fix required", "rationale": "The 14 documents resolve to 11 distinct publishers once the two EU, two CFPB and two HMRC items are collapsed. The count is defensible but reads as an undercount; the claim must say 14 documents from 11 independent publishers so a reviewer is not left to reconstruct the arithmetic." }, { "concept": "SRC-001 FIBO retrieved from a master-branch raw URL and SRC-012 ISO 20022 live catalogue", "disposition": "rejected as stable citations; require immutable pins before publication", "rationale": "Both URLs are mutable targets, so the artifact identity rule fails: a reviewer cannot retrieve what was read. FIBO must be pinned to a commit or release tag alongside the stated FBC/20260701 version IRI, and the ISO 20022 catalogue must be pinned by retrieval date and captured message-definition list." }, { "concept": "SRC-013 ISO 13616-1:2020 cited as tier-1 primary support for check-digit validation", "disposition": "reclassified to bibliographic reference; evidentiary weight carried by SRC-008", "rationale": "The iso.org page is a catalogue entry, and the known omissions confirm the IBAN Registry file did not render. The normative structure text was not read, so validation-and-quality-controls is in substance grounded on the Bundesbank rendering and must say so rather than implying the standard was consulted." }, { "concept": "Beneficial ownership threshold support: q-bo-threshold cited only to SRC-006 (GLEIF LEI) and SRC-010 (HMRC)", "disposition": "rejected as adequate support; no threshold or control prong may be asserted", "rationale": "GLEIF LEI material identifies legal entities and parent relationships, not AML beneficial ownership determinations, so the cited set contains no authority that states a threshold. The omission note claims EU and HMRC proxies but SRC-004 is not on the finding. The question stays parameterized with the regime named and no numeric value published." }, { "concept": "pricing-and-interest-terms grounded on SRC-003 alone", "disposition": "deferred: add a second authority or scope the finding regionally before promotion", "rationale": "Directive 2014/92/EU addresses fee comparability, switching and basic-features access; it is a thin anchor for q-fee-interest on credit and debit balance interest determination, and it is EU-bound while the finding is stated generally. Single-source, single-jurisdiction support cannot carry a globally phrased finding." }, { "concept": "derive-dormancy-candidacy: three terms (candidacy, designation, determination) for one output, sourced only to SRC-005", "disposition": "accepted with rename and jurisdiction parameter", "rationale": "The scope statement, the finding and the function each name the same artefact differently, which will fracture downstream references. Normalise to determination, and make the jurisdictional test an explicit input, since the only cited authority is the UK fifteen-year statutory test and the recorded conflict states dormancy cannot be a global constant." }, { "concept": "Artifact serial flags on beneficial-ownership-certification, tax-self-certification-record and depositor-information-sheet", "disposition": "deferred: re-evaluate serial=true pending live source verification", "rationale": "q-bo-refresh asks what triggers re-confirmation and q-ev-valid asks what triggers refresh, which implies repeated dated instances rather than one document, and periodic re-provision of depositor information should be confirmed against the guarantee-scheme text. Serial=false on a re-issued instrument breaks artifact identity and supersession." }, { "concept": "assemble-account-context-package sourced to SRC-002 and SRC-009", "disposition": "reclassified as a platform-plane function; drop the subject-source claim", "rationale": "Bootstrap files, bundle structure and resolvable artifact references are Vercy packaging semantics. Neither the Open Banking accounts resource nor the CFPB rule speaks to package assembly, so the citation implies external support that does not exist." }, { "concept": "Function coverage against the finding set", "disposition": "deferred to a revision pass; no functions added in this audit", "rationale": "Restriction and freeze designation, protection-scheme designation, switching execution, closure, evidence registration and validation-run emission are findings with artifacts but no corresponding function. Single-provider mode forbids adding functions here, so the gap is recorded for the revision rather than silently closed." } ], "publicationHolds": [ "Single-provider hold: this result was produced by Claude alone under an owner-authorized waiver of Grok recorded at 2026-08-29T09:06:27Z after repeated structured-output failures. No independent second-provider review exists and none was attempted. Every published artifact, page header and export must carry this waiver visibly, and the result stays a reviewable draft with review_state boundary-review-required until an independent provider or a human domain reviewer signs off.", "Live source and version verification hold: all 14 sources must be re-retrieved and pinned before publication. SRC-001 is a mutable master-branch raw URL, SRC-012 is a live catalogue, and SRC-006, SRC-007 and SRC-008 are undated 'current guidance' pages captured on 29 August 2026. Each requires a commit, edition or retrieval-date pin plus a content digest, or it must be demoted from primary support.", "Regulatory currency hold on the access designation: SRC-009 is the October 2024 CFPB final rule and SRC-014 is an August 2025 advance notice of reconsideration, both now more than a year old relative to the 29 August 2026 research date. The obligation status must be re-verified at publication and the model must continue to record it as contested rather than in force.", "Unread normative text hold: the ISO 20022 e-Repository CashAccount component, the ISO 13616 IBAN Registry file and the ISO 13616-1:2020 standard text were never read. All ISO-derived element-level statements must publish as alignment only, with conformance explicitly withheld and the interoperability checklist entry downgraded from covered to partial.", "Unverified AML detail hold: FATF Recommendations 10 and 11 and 31 CFR 1010.230 were blocked, so no beneficial-ownership threshold, control prong or record-keeping period may be published as a value. These stay parameterized, with the regime named and the value marked unverified.", "Coverage-claim hold: the security, privacy, access, retention and interoperability checklist entries must be downgraded to partial, and the source count restated as 14 documents from 11 independent publishers, before the coverage block is published.", "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft." ], "deferredResearch": [ "Retrieve FATF Recommendations 10 and 11 and FinCEN 31 CFR 1010.230 through an alternate non-blocked channel to ground the beneficial-ownership threshold, the control prong and the five-year record-keeping rule that currently rest on HMRC and EU proxies.", "Retrieve the ISO 20022 e-Repository CashAccount business component and the ISO 13616 IBAN Registry file to replace the Bundesbank and Open Banking renderings with element-level normative support for identifier structure and validation.", "Cite the OECD Common Reporting Standard primary text directly instead of relying on HMRC internal manual pages IEIM401505 and IEIM401540 as the only support for tax-status-classification, including the 1 January 2026 depository-account expansion.", "Verify United States state unclaimed-property dormancy periods and the Revised Uniform Unclaimed Property Act so dormancy is grounded in more than the UK fifteen-year statutory test before derive-dormancy-candidacy is parameterized by jurisdiction.", "Confirm whether planning/VERCY-MODEL-RELATIONS.csv holds an inbound CONTAINS row from WM-XCT-014 to WM-ECO-015, since the registry asserts the parent but the frozen contract shows only the two outbound rows.", "Decide whether the seven unregistered neighbour references (party master, consent and authorisation, payment instruction, product catalogue, deposit guarantee scheme, unclaimed property, and any statement-rendering owner) need registered REFERENCE rows, and register them before those boundary notes become typed edges.", "Open an account-group model candidate covering cross-institution aggregation, umbrella and relationship accounts, notional pooling and virtual account hierarchies, together with securities and custody account decomposition, Islamic and profit-sharing structures, escrow and client-money segregation, and tokenised deposit identifier schemes, all currently declared as gaps or under-modelled." ] }, "statistics": { "sources": 14, "bundles": 6, "layers": 14, "findings": 26, "questions": 102, "artifacts": 16, "functions": 11 } }