# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-25T19:21:49Z", "synthesisSha256": "75807af45a2177a2a873c440d8bc1c0fbe82a65c3c7eed695e39a180e8f88788", "providers": [ "Claude", "Grok" ] }, "metaModel": { "id": "WM-ECO-009", "registryId": "vr.wm-eco-009", "name": "Payment", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Society, people and institutions", "industry": [ "Cross-industry" ], "domain": [ "SOC.ECO.PAY" ], "tags": [ "payment", "soc.eco.pay" ], "status": "research draft" }, "canonicalUrl": "https://ver.cy/models/wm-eco-009-payment/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-eco-009", "model": { "registry_id": "vr.wm-eco-009", "model_id": "WM-ECO-009", "name": "Payment", "entry_kind": "aggregate", "purpose": "Provide the format-neutral context an agent needs to understand, create, inspect and operate a payment: an instructed transfer of funds from a payer to a payee that discharges or modifies a monetary obligation, together with its authorisation, routing, clearing, settlement, finality, evidence and exception handling.", "scope_statement": "The model covers the payment as a legal and operational act and as an aggregate: the payment order and its receipt, the consent and authorisation that make it authorised, the amount and denomination, the party and account references it carries, the rail and routing chain, the clearing cycle and settlement event, the finality point at which the underlying obligation is discharged, the status and lifecycle history, the exception paths (refusal, revocation, return, recall, refund, chargeback, unauthorised-transaction claims), the evidence produced (advices, confirmations, statements), and the governance of access, retention and deletion of payment records. It is deliberately independent of storage format and access interface: ISO 20022 XML, card network messages, ledger rows, files or API payloads are projections of the same semantics. Money itself, accounts as entities, invoices and accounting postings are referenced through sibling models rather than restated here.", "in_scope": [ "Payment order identity, references and correlation across legs and participants (end-to-end reference, instruction reference, clearing system reference)", "Payment classification: instrument class, scheme, local instrument, service level and category purpose", "Instructed, settlement and equivalent amounts, currency denomination, minor units and currency conversion", "Charges, fees and charge-bearer allocation between payer and payee", "Payer, payee, initiating party, ultimate parties and the ordered chain of agents", "Party and account identification data carried with the payment, including structured address and identifier schemes", "Consent, authorisation, authentication evidence and the authorised/unauthorised determination", "Receipt of the payment order, cut-off times, business-day calendars and refusal", "Revocability, revocation deadlines, amendment and cancellation or recall requests", "Rail and routing selection, settlement method and the intermediary chain", "Clearing cycle, gross versus net settlement, settlement asset and prefunding", "Settlement execution, settlement date, value date, funds availability and execution deadlines", "Settlement finality, irrevocability and discharge of the underlying monetary obligation", "Status codes, status reason codes and the lifecycle event history", "Returns, reversals, recalls, refunds, chargebacks, disputes and error resolution", "Confirmations, advices, statements and reconciliation to ledger postings", "Compliance data that must travel with the payment, and access, retention and deletion of payment records" ], "out_of_scope": [ "Money as an instrument: currency catalogue governance, cash classes, deposit and electronic-money issuance and redemption (WM-ECO-004)", "Accounts, wallets and balances as first-class entities; the payment references them and does not own their lifecycle", "Invoices, bills and demand documents and their own lifecycle (WM-ECO-008)", "Double-entry postings, journals, trial balance and accounting policy (WM-ECO-016)", "Credit claims, loans, interest accrual and debt instruments; their cash flows appear here only as payments", "Natural persons and organizations as entities; only role references are held", "The contract or agreement that creates the obligation, and the goods, services or rights being paid for", "Tax determination, withholding calculation and statutory tax filing", "Securities settlement legs, delivery-versus-payment asset legs and trade lifecycle", "Customer onboarding, KYC file content and firm-level compliance programme design", "Pricing, discounting, dunning and collections strategy", "Payroll entitlement calculation and benefits administration" ], "boundary_notes": [ { "neighbor": "WM-ECO-004 Money and Monetary Instrument", "distinction": "That model owns what money is: units of account, minor units, instrument forms and issuance. This model owns the transfer act. A currency code or instrument form is referenced by scheme and version here, never redefined; conversely a settlement finality rule belongs here, not there.", "source_refs": [ "SRC-009", "SRC-007" ] }, { "neighbor": "WM-ECO-016 Financial Transaction and Posting", "distinction": "A payment is an economic and legal act on a rail; a posting is its representation in a ledger under an accounting policy. One payment may generate several postings in several ledgers, and a posting may exist with no payment. The handoff is a COMPOSE relation, not an identity.", "source_refs": [ "SRC-012", "SRC-007" ] }, { "neighbor": "WM-ECO-008 Invoice", "distinction": "The invoice states the obligation and its amount; the payment discharges it. Allocation of a payment across invoices is held here as a linkage, while invoice line detail, tax lines and dunning state remain in the invoice model.", "source_refs": [ "SRC-005", "SRC-001" ] }, { "neighbor": "Account and Holding model", "distinction": "The payment carries account references and unique identifiers, and asserts value date and availability effects, but does not own account opening, mandate registers, balances or statement generation. This neighbour is not yet present in the registry and is recorded as an unresolved boundary.", "source_refs": [ "SRC-001", "SRC-002" ] }, { "neighbor": "Dispute and case management", "distinction": "Chargeback, error-resolution and unauthorised-transaction cases have their own investigatory workflow, provisional credit and evidence packs. This model holds the payment-side case linkage, deadlines and liability outcome; deeper case workflow belongs to an EXTEND sibling.", "source_refs": [ "SRC-013", "SRC-002" ] }, { "neighbor": "Card scheme and acquiring domain", "distinction": "Card authorisation, capture, clearing files and interchange are a specialisation of this aggregate rather than a separate concern; but cardholder data protection obligations and credential tokenisation are governed by an external security standard aligned to, not absorbed by, this model.", "source_refs": [ "SRC-014", "SRC-001" ] }, { "neighbor": "Crypto-asset and e-money token transfers", "distinction": "Transfers of e-money tokens referencing one official currency behave as payments but sit under a distinct authorisation regime. They are modelled as an EXTEND specialisation so that issuer authorisation, reserve and white-paper obligations do not leak into the core payment aggregate.", "source_refs": [ "SRC-015" ] } ] }, "sources": [ { "id": "SRC-001", "title": "The Payment Services Regulations 2017 (S.I. 2017/752), regulation 2 (Interpretation)", "organization": "UK Government / The National Archives (legislation.gov.uk)", "url": "https://www.legislation.gov.uk/uksi/2017/752/regulation/2/made", "version_or_date": "S.I. 2017/752, as made 18 July 2017", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:05:00Z", "relevance": "Normative definitions of payment transaction, payment order, payer, payee, payment instrument, payment account, funds, unique identifier, value date, acquiring and issuing. Anchors the core vocabulary of the aggregate." }, { "id": "SRC-002", "title": "The Payment Services Regulations 2017, Part 7 (Rights and obligations in relation to the provision of payment services)", "organization": "UK Government / The National Archives (legislation.gov.uk)", "url": "https://www.legislation.gov.uk/uksi/2017/752/part/7/made", "version_or_date": "S.I. 2017/752, Part 7, as made 18 July 2017", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:07:00Z", "relevance": "Receipt of payment orders, refusal and reasons, withdrawal of consent and revocation deadlines, incorrect unique identifiers, liability for non-execution or defective execution, and unauthorised transaction refund and notification windows." }, { "id": "SRC-003", "title": "The Payment Services Regulations 2017, regulation 86 (Payment transactions to a payment account)", "organization": "UK Government / The National Archives (legislation.gov.uk)", "url": "https://www.legislation.gov.uk/uksi/2017/752/regulation/86/made", "version_or_date": "S.I. 2017/752, regulation 86, as made 18 July 2017", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:24:00Z", "relevance": "Maximum execution times measured from time of receipt, the extended limit for paper-initiated orders, the longer limit for certain intra-area transactions, and the obligation to value date and credit on receipt of funds." }, { "id": "SRC-004", "title": "Uniform Commercial Code § 4A-103. Payment Order — Definitions", "organization": "Cornell Law School Legal Information Institute (text of the Uniform Commercial Code, ALI and ULC)", "url": "https://www.law.cornell.edu/ucc/4A/4A-103", "version_or_date": "UCC Article 4A, LII online edition consulted 2026", "source_type": "legislation", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:12:00Z", "relevance": "Defines payment order and the three conditions that make an instruction a payment order, plus beneficiary, beneficiary's bank, receiving bank and sender. Supplies a second, independent legal framing of the instruction and agent-chain roles." }, { "id": "SRC-005", "title": "Uniform Commercial Code § 4A-406. Payment by Originator to Beneficiary; Discharge of Underlying Obligation", "organization": "Cornell Law School Legal Information Institute (text of the Uniform Commercial Code, ALI and ULC)", "url": "https://www.law.cornell.edu/ucc/4A/4A-406", "version_or_date": "UCC Article 4A, LII online edition consulted 2026", "source_type": "legislation", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:12:00Z", "relevance": "Fixes the moment payment occurs (acceptance by the beneficiary's bank), the conditional discharge of the underlying obligation, the four exceptions to discharge, and the treatment of deducted bank charges." }, { "id": "SRC-006", "title": "Payment Request API", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/payment-request/", "version_or_date": "Candidate Recommendation Draft, 22 June 2026", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:09:00Z", "relevance": "Provides an interface-neutral payment request state machine (created, interactive, closed), PaymentCurrencyAmount with an ISO 4217 currency and decimal value, payment method identifiers and PaymentResponse. Evidence that payment-method identity and amount are separable, portable concepts." }, { "id": "SRC-007", "title": "Principles for Financial Market Infrastructures (PFMI)", "organization": "Committee on Payments and Market Infrastructures (CPSS) and IOSCO, Bank for International Settlements", "url": "https://www.bis.org/cpmi/publ/d101.htm", "version_or_date": "16 April 2012", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:06:00Z", "relevance": "International standards for payment, clearing and settlement systems, covering settlement finality, money settlements, exchange-of-value settlement and participant default. Grounds the clearing, settlement-asset and finality layers." }, { "id": "SRC-008", "title": "CPMI Glossary (glossary of terms used in payments and market infrastructure)", "organization": "Committee on Payments and Market Infrastructures, Bank for International Settlements", "url": "https://www.bis.org/cpmi/publ/d00b.htm", "version_or_date": "17 October 2016", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:06:00Z", "relevance": "The authoritative terminology register for payment, clearing and settlement vocabulary. Used only as a pointer to canonical term governance: the underlying PDF could not be text-extracted during this research, so it never carries a structural node on its own." }, { "id": "SRC-009", "title": "Data standards — ISO 4217 Currency Codes (Maintenance Agency)", "organization": "SIX Group, ISO 4217 Maintenance Agency under the Swiss Association for Standardization", "url": "https://www.six-group.com/en/products-services/financial-information/data-standards.html", "version_or_date": "Currency code lists, amendment effective 1 January 2026", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:14:00Z", "relevance": "Registration-authority source for alphabetic and numeric currency codes, minor unit (decimal places), currency name and country, plus funds codes and historic currencies. Governs denomination and amount scaling by reference rather than by copy." }, { "id": "SRC-010", "title": "T2 — TARGET Services real-time gross settlement", "organization": "European Central Bank", "url": "https://www.ecb.europa.eu/paym/target/t2/html/index.en.html", "version_or_date": "T2 live since March 2023; page consulted August 2026", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:14:00Z", "relevance": "Real-time gross settlement in central bank money with immediate finality, Central Liquidity Management, ISO 20022 messaging, and a defined operating day and closing calendar. Evidence for settlement asset, liquidity, calendar and finality semantics." }, { "id": "SRC-011", "title": "ISO 20022 Business Areas", "organization": "ISO 20022 Registration Authority", "url": "https://www.iso20022.org/sites/default/files/media/file/ISO20022_BusinessAreas.pdf", "version_or_date": "Produced by the ISO 20022 Registration Authority, 4 June 2025", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:18:00Z", "relevance": "Registration-authority list of four-character business area codes, including pain (payments initiation), pacs (payments clearing and settlement), camt (cash management), remt (remittance) and acmt (account management). Grounds the initiation / clearing / reporting separation used across bundles." }, { "id": "SRC-012", "title": "Fedwire Funds Service ISO 20022 Format Frequently Asked Questions", "organization": "Federal Reserve Financial Services", "url": "https://www.frbservices.org/resources/financial-services/wires/faq/iso-20022/format", "version_or_date": "Post-migration guidance; Fedwire Funds Service migrated to ISO 20022 on 14 July 2025", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:18:00Z", "relevance": "Operator-level detail on value and non-value messages (pacs.008, pacs.009, pacs.004, pacs.002, pacs.028, camt.056, camt.029, camt.110/111, pain.013/014), mandatory UETR, structured postal address requirements, and charge bearer codes SHAR, CRED, DEBT and SLEV." }, { "id": "SRC-013", "title": "Regulation E, 12 CFR § 1005.11 — Procedures for resolving errors", "organization": "Consumer Financial Protection Bureau (CFPB)", "url": "https://www.consumerfinance.gov/rules-policy/regulations/1005/11/", "version_or_date": "12 CFR Part 1005 (Regulation E), current version consulted August 2026", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:22:00Z", "relevance": "Defines what counts as an error, the 60-day consumer notice window, 10 and 45 business day investigation limits, provisional credit obligations and result-reporting duties. Anchors dispute and error-resolution timing as normative rather than customary." }, { "id": "SRC-014", "title": "PCI Data Security Standard (PCI DSS)", "organization": "PCI Security Standards Council", "url": "https://www.pcisecuritystandards.org/standards/pci-dss/", "version_or_date": "PCI DSS v4.x, standard page consulted August 2026", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:20:00Z", "relevance": "Establishes the scope concept of cardholder data and sensitive authentication data and the population of entities that store, process or transmit it. Grounds credential handling, access scoping and retention/deletion constraints for card-borne payments." }, { "id": "SRC-015", "title": "Markets in Crypto-Assets Regulation (MiCA), Regulation (EU) 2023/1114", "organization": "European Securities and Markets Authority (ESMA)", "url": "https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica", "version_or_date": "Regulation (EU) 2023/1114; in force June 2023, fully applicable December 2024, transitional period to 1 July 2026", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:24:00Z", "relevance": "Regulated categories of e-money tokens (Title IV) and asset-referenced tokens (Title III) with issuer authorisation duties. Evidence that token-denominated transfers form a distinct regulatory regime and must be an EXTEND specialisation rather than a core payment variant." }, { "id": "SRC-016", "title": "ISO 20022 Message Definitions — Payments Initiation (pain) and Payments Clearing and Settlement (pacs)", "organization": "ISO 20022 Registration Authority", "url": "https://www.iso20022.org/iso-20022-message-definitions", "version_or_date": "pain and pacs message sets last updated 11 March 2024; catalogue accessed 2026-08-25", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Defines payment identifiers, agent chain, amounts, charge bearer, status, return, mandate and remittance semantics used throughout this model." }, { "id": "SRC-017", "title": "A glossary of terms used in payments and settlement systems (CPMI Glossary)", "organization": "Bank for International Settlements, Committee on Payments and Market Infrastructures", "url": "https://www.bis.org/cpmi/glossary.pdf", "version_or_date": "Updated 17 October 2016; PDF accessed 2026-08-25", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Supplies the definitions of payment, payment system, clearing, netting, settlement, final settlement and settlement lag." }, { "id": "SRC-018", "title": "Principles for Financial Market Infrastructures — Principle 8 Settlement finality, Principle 9 Money settlements, Principle 12 Exchange-of-value settlement systems, Principle 22 Communication procedures and standards", "organization": "CPMI and IOSCO / Bank for International Settlements", "url": "https://www.bis.org/pfmi/help/principleid.htm", "version_or_date": "PFMI April 2012 (CPSS-IOSCO, BIS paper d101); principle index accessed 2026-08-25", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Grounds settlement finality, money settlements, exchange-of-value linkage and communication standards for payments carried by an FMI." }, { "id": "SRC-019", "title": "Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market (PSD2)", "organization": "European Union (Official Journal L 337/35, 23.12.2015)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015L2366", "version_or_date": "25 November 2015; OJ 23 December 2015; accessed 2026-08-25", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Defines payer, payee, payment transaction, payment order, unique identifier, authentication, PISP liability, execution clocks and refund rights." }, { "id": "SRC-020", "title": "Uniform Commercial Code Article 4A — Funds Transfers, including §§ 4A-103 Payment order, 4A-104 Funds transfer, 4A-209 Acceptance, 4A-406 Payment by originator to beneficiary; obligation of beneficiary to refund", "organization": "Uniform Law Commission / Cornell Legal Information Institute", "url": "https://www.law.cornell.edu/ucc/4A/4A-104", "version_or_date": "UCC Article 4A as published on LII; §§ 4A-103 and 4A-104 fetched 2026-08-25", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Defines payment order, funds transfer, the party chain, acceptance by banks and discharge of the underlying obligation." }, { "id": "SRC-021", "title": "SEPA Credit Transfer rulebook and implementation guidelines (2025 SCT rulebook version 1.1)", "organization": "European Payments Council AISBL", "url": "https://www.europeanpaymentscouncil.eu/what-we-do/epc-payment-schemes/sepa-credit-transfer/sepa-credit-transfer-rulebook-and", "version_or_date": "2025 SCT rulebook version 1.1 published October 2025; in effect up to and including 21 November 2027; page accessed 2026-08-25", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Scheme rules for euro credit transfers: aliases and proxies, recall initiation, R-transaction reason codes and address-format transition." }, { "id": "SRC-022", "title": "FATF updates Standards on Recommendation 16 on payment transparency", "organization": "Financial Action Task Force", "url": "https://www.fatf-gafi.org/en/publications/Fatfrecommendations/update-Recommendation-16-payment-transparency-june-2025.html", "version_or_date": "18 June 2025; accessed 2026-08-25", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Requires accurate originator and beneficiary information on wire transfers and assigns information responsibilities along the payment chain." }, { "id": "SRC-023", "title": "Harmonised ISO 20022 data requirements for enhancing cross-border payments", "organization": "Bank for International Settlements, Committee on Payments and Market Infrastructures", "url": "https://www.bis.org/cpmi/publ/d218.htm", "version_or_date": "17 October 2023 (CPMI Papers d218); page accessed 2026-08-25", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Defines the minimum end-to-end data set and consistent identification required for cross-border payment interoperability." }, { "id": "SRC-024", "title": "Regulation (EU) No 260/2012 as amended — credit transfers and direct debits in euro, including instant credit transfer", "organization": "European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02012R0260-20240408", "version_or_date": "Consolidated text 8 April 2024; accessed 2026-08-25", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Defines instant credit transfer, time of receipt, the ten-second availability and confirmation duties and the payee-verification overlay." }, { "id": "SRC-025", "title": "Information accompanying transfers of funds and certain crypto-assets (recast of Regulation (EU) 2015/847 / Transfer of Funds Regulation)", "organization": "European Union / EUR-Lex", "url": "https://eur-lex.europa.eu/EN/legal-content/summary/information-accompanying-transfers-of-funds-and-certain-crypto-assets.html", "version_or_date": "EUR-Lex summary of the recast transfer-of-funds rules; page accessed 2026-08-25", "source_type": "legislation", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Requires payer and payee information to accompany transfers of funds, verification before execution and detection of missing data." }, { "id": "SRC-026", "title": "Methodology of the statistics on payments and financial market infrastructures in the CPMI countries", "organization": "Bank for International Settlements, Committee on Payments and Market Infrastructures", "url": "https://www.bis.org/cpmi/publ/d168.pdf", "version_or_date": "August 2017 (CPMI Papers d168); accessed via BIS PDF 2026-08-25", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Classifies payment instruments (credit transfer, direct debit, card, e-money, cheque) and the domestic versus cross-border rule." } ], "structure": { "bundles": [ { "id": "identity-classification-and-value", "name": "Payment Identity, Classification and Value", "description": "What this payment is, how it is referenced across every participant, what class and scheme it belongs to, and the monetary quantity it moves including conversion and charges.", "rationale": "Nothing downstream can be routed, matched, disputed or posted without a stable reference set, a type that selects the applicable rulebook, and an unambiguous amount in a governed currency. Legal texts define the payment transaction and its amount as constitutive elements, and operator guidance makes end-to-end references and charge bearer mandatory fields.", "source_refs": [ "SRC-001", "SRC-004", "SRC-009", "SRC-011", "SRC-012" ], "layers": [ { "id": "identification-and-typing", "name": "Identification and Typing", "description": "The reference identifiers that correlate one economic payment across legs, participants and messages, and the classification that selects the governing scheme and rulebook.", "source_refs": [ "SRC-011", "SRC-012", "SRC-004" ], "findings": [ { "id": "payment-reference-identifiers", "name": "Payment reference identifiers and their correlation", "description": "A single economic payment carries several distinct references: one assigned by the initiating party, one assigned by the debtor agent, one or more assigned by clearing systems, and an end-to-end reference intended to survive every hop. Operator rules make an end-to-end transaction reference mandatory on value messages and check its format but not its uniqueness, so identity resolution must be explicit about which reference is authoritative and which are merely correlating.", "source_refs": [ "SRC-012", "SRC-011", "SRC-004" ], "questions": [ { "id": "q-master-reference", "text": "Which single identifier is the authoritative master reference for this payment, and which system of record assigns it?", "kind": "identity", "answer_data": [ "Master identifier value", "Assigning system or scheme name", "Assignment scope (global, scheme, participant)" ] }, { "id": "q-reference-correlation", "text": "How are initiating-party, instructing-agent, clearing-system and end-to-end references held distinct while remaining correlatable?", "kind": "relationship", "answer_data": [ "Reference type", "Reference value", "Assigning participant reference", "Correlation role (authoritative, alias, leg-local)" ] }, { "id": "q-reference-uniqueness-check", "text": "Who verifies that the end-to-end reference is unique, and what happens when uniqueness is only format-checked?", "kind": "validation", "answer_data": [ "Uniqueness check performed (boolean)", "Checking party", "Duplicate detection outcome", "Collision handling rule" ] }, { "id": "q-reference-passthrough", "text": "Which references must intermediaries pass through unaltered, and which may they replace on their own leg?", "kind": "interoperability", "answer_data": [ "Pass-through obligation flag per reference type", "Governing scheme rule reference", "Observed alterations across legs" ] } ], "data_elements": [ { "id": "end-to-end-identification", "name": "End-to-end identification", "description": "Reference supplied by the initiating party and intended to reach the payee unchanged.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-011" ] }, { "id": "unique-end-to-end-transaction-reference", "name": "Unique end-to-end transaction reference", "description": "Universally unique reference used as the end-to-end tracking key on value messages; mandatory on some rails.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "instruction-identification", "name": "Instruction identification", "description": "Reference assigned by the instructing agent for one leg of the payment.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-004" ] }, { "id": "clearing-system-reference", "name": "Clearing system reference", "description": "Reference assigned by the clearing or settlement system that carried the payment.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-010" ] } ], "artifacts": [ { "id": "payment-identifier-crosswalk", "name": "Payment identifier crosswalk", "description": "A resolved mapping of every reference observed for one economic payment against the participant that assigned it and the leg on which it appeared, marking exactly one as authoritative.", "media_or_form": [ "tabular reference set", "structured record", "graph edge set" ], "serial": false, "identity_strategy": "Keyed by the payment's authoritative master identifier; the crosswalk mints no identifier of its own and is regenerated rather than versioned when new legs are observed.", "source_refs": [ "SRC-012", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "payment-type-and-scheme-classification", "name": "Payment type, scheme and service level classification", "description": "Classification selects the rulebook. Instrument class (credit transfer, direct debit, card transaction, cash, instant transfer), the scheme or clearing system, the local instrument, service level and category purpose jointly determine execution deadlines, revocability, return rights and dispute mechanics. Legal definitions of acquiring and issuing further split card-type payments by the contracting side.", "source_refs": [ "SRC-001", "SRC-011", "SRC-012", "SRC-006" ], "questions": [ { "id": "q-instrument-class", "text": "What instrument class and scheme does this payment belong to, and which rulebook version therefore governs it?", "kind": "classification", "answer_data": [ "Instrument class code", "Scheme or clearing system identifier", "Rulebook version reference" ] }, { "id": "q-classification-consequences", "text": "Which execution deadline, revocability rule and return right follow from the chosen classification rather than from party agreement?", "kind": "constraint", "answer_data": [ "Derived execution deadline", "Derived revocability rule", "Derived return window", "Source of the rule (statute, rulebook, contract)" ] }, { "id": "q-scheme-selection", "text": "On what basis was this scheme selected over an eligible alternative, and who made that choice?", "kind": "decision", "answer_data": [ "Selection criteria applied", "Rejected alternatives", "Deciding party reference", "Decision timestamp" ] }, { "id": "q-classification-mapping", "text": "How does this classification map onto an external payment method identifier used by an ordering channel?", "kind": "interoperability", "answer_data": [ "External payment method identifier", "Mapping confidence", "Unmapped residual attributes" ] } ], "data_elements": [ { "id": "payment-instrument-class-code", "name": "Payment instrument class code", "description": "Class of the payment such as credit transfer, direct debit, card transaction, cash or instant transfer.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-011" ] }, { "id": "scheme-identifier", "name": "Scheme or clearing system identifier", "description": "Identifier of the scheme or clearing system whose rulebook governs the payment.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-010" ] }, { "id": "local-instrument-code", "name": "Local instrument code", "description": "Scheme-specific product or instrument variant applied to the payment.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "service-level-code", "name": "Service level code", "description": "Agreed service level such as a priority or instant service that constrains execution timing.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-003" ] } ], "artifacts": [ { "id": "payment-scheme-profile", "name": "Payment scheme profile", "description": "A machine-readable profile of one scheme or rail stating its supported instrument classes, execution deadlines, cut-offs, revocability rules, return windows and mandatory data elements, used to validate and constrain payments classified into it.", "media_or_form": [ "configuration profile", "capability descriptor", "rulebook extract" ], "serial": true, "identity_strategy": "Identified by scheme identifier plus rulebook version; each published rulebook version yields a new serial profile and prior profiles are retained for reconstructing historic payments.", "source_refs": [ "SRC-012", "SRC-011", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "instrument-class-and-initiation-direction", "name": "Payment instrument class and initiation direction", "description": "CPMI statistics treat payment instruments as credit transfers, direct debits, card payments, e-money payments and cheques. A credit transfer is a payment order, or sequence of orders, made to place funds at the disposal of the payee, with both the order and the funds moving from the payer's institution to the payee's institution. A direct debit is a preauthorised debit of the payer's account initiated by the payee. PSD2 defines a payment transaction as an act, initiated by the payer or on his behalf or by the payee, of placing, transferring or withdrawing funds, irrespective of any underlying obligations. Instant credit transfer is a credit transfer executed immediately, 24 hours a day on any calendar day. Cash and card remain instrument classes even when detailed till or scheme-clearing rules live elsewhere.", "source_refs": [ "SRC-026", "SRC-019", "SRC-024", "SRC-017" ], "inline_only_rationale": null, "data_elements": [ { "id": "instrument-class-and-initiation-direction-data01", "name": "instrument_class", "description": "Instrument family: credit transfer, direct debit, card, e-money, cheque or cash.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026", "SRC-019", "SRC-024", "SRC-017" ] }, { "id": "instrument-class-and-initiation-direction-data02", "name": "initiation_direction", "description": "Whether the transfer is pushed by the payer or pulled by the payee.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026", "SRC-019", "SRC-024", "SRC-017" ] }, { "id": "instrument-class-and-initiation-direction-data03", "name": "scheme_id", "description": "Identifier of the scheme or rail product governing the transfer.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026", "SRC-019", "SRC-024", "SRC-017" ] }, { "id": "instrument-class-and-initiation-direction-data04", "name": "instant_indicator", "description": "Whether the transfer is executed immediately, 24 hours a day on any calendar day.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026", "SRC-019", "SRC-024", "SRC-017" ] }, { "id": "instrument-class-and-initiation-direction-data05", "name": "service_level", "description": "Scheme service level agreed for execution.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026", "SRC-019", "SRC-024", "SRC-017" ] }, { "id": "instrument-class-and-initiation-direction-data06", "name": "local_instrument", "description": "Local instrument code qualifying the scheme product.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026", "SRC-019", "SRC-024", "SRC-017" ] }, { "id": "instrument-class-and-initiation-direction-data07", "name": "category_purpose", "description": "Category purpose code classifying the transfer for scheme handling.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026", "SRC-019", "SRC-024", "SRC-017" ] }, { "id": "instrument-class-and-initiation-direction-data08", "name": "domestic_or_cross_border", "description": "Whether payer and payee account-servicing institutions sit in the same jurisdiction.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026", "SRC-019", "SRC-024", "SRC-017" ] } ], "artifacts": [ { "id": "instrument-class-and-initiation-direction-artifact01", "name": "CPMI payments statistics methodology — payment instrument types and domestic versus cross-border rules", "description": "Methodology text enumerating the payment instrument classes and the domestic versus cross-border rule used for statistics.", "media_or_form": [ "Published methodology document (PDF)" ], "serial": false, "identity_strategy": "Identified by the CPMI paper number and section reference.", "source_refs": [ "SRC-026" ] }, { "id": "instrument-class-and-initiation-direction-artifact02", "name": "SEPA Regulation consolidated definition of instant credit transfer and payment initiation channel", "description": "Consolidated legislative text defining instant credit transfer and how such orders are initiated.", "media_or_form": [ "Consolidated legislative text (EUR-Lex HTML)" ], "serial": false, "identity_strategy": "Identified by CELEX number, consolidation date and article reference.", "source_refs": [ "SRC-024" ] } ], "questions": [ { "id": "instrument-class-and-initiation-direction-q01", "text": "Is this payment a credit transfer, direct debit, card, e-money, cheque, cash or another instrument class, and is it instant or non-instant?", "kind": "classification", "answer_data": [ "instrument_class (enum)", "instant_indicator (boolean)", "local_instrument (string)" ] }, { "id": "instrument-class-and-initiation-direction-q02", "text": "Was the payment order initiated by the payer (push), by the payee under a mandate (pull), by a PISP on behalf of the payer, or by a request-to-pay accepted by the payer?", "kind": "relationship", "answer_data": [ "initiation_direction (enum)", "initiating_party_role (enum)", "pisp_party_ref (party-ref)" ] }, { "id": "instrument-class-and-initiation-direction-q03", "text": "Which scheme or rail product governs the transfer, and is it domestic or cross-border given the residency of the payer's and payee's account-servicing institutions?", "kind": "constraint", "answer_data": [ "scheme_id (string)", "service_level (string)", "domestic_or_cross_border (enum)", "payer_psp_jurisdiction (iso-3166)", "payee_psp_jurisdiction (iso-3166)" ] } ] } ] }, { "id": "amount-denomination-and-charges", "name": "Amount, Denomination and Charges", "description": "The monetary quantity moved, the governed currency and scale that make it interpretable, any conversion applied, and how costs are borne between the parties.", "source_refs": [ "SRC-009", "SRC-006", "SRC-012", "SRC-005" ], "findings": [ { "id": "instructed-and-settlement-amount", "name": "Instructed, settlement and equivalent amounts", "description": "A payment order specifies a fixed or determinable amount of money. The instructed amount, the amount actually settled between agents, and any equivalent amount in another currency are distinct values that may diverge because of conversion or deducted charges. Currency identity and decimal scale are governed externally by the currency code registry, which publishes alphabetic code, numeric code and minor unit.", "source_refs": [ "SRC-004", "SRC-009", "SRC-006", "SRC-005" ], "questions": [ { "id": "q-amount-determinacy", "text": "Is the amount fixed at instruction time or determinable later, and what rule determines it?", "kind": "definition", "answer_data": [ "Determinacy flag", "Determination rule text or reference", "Determination time" ] }, { "id": "q-amount-scale-validation", "text": "How is the amount validated against the governed minor unit of its currency, and what is done with excess precision?", "kind": "validation", "answer_data": [ "Currency alphabetic code", "Minor unit from registry", "Scale of submitted value", "Rejection or rounding rule applied" ] }, { "id": "q-amount-divergence", "text": "Where the settled amount differs from the instructed amount, what accounts for the difference?", "kind": "measurement", "answer_data": [ "Instructed amount", "Settlement amount", "Difference cause code (conversion, charges, partial)", "Difference value" ] } ], "data_elements": [ { "id": "instructed-amount", "name": "Instructed amount", "description": "Amount of money the payer instructed to be transferred, expressed in a stated currency.", "value_kind": "quantity", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "instructed-currency-code", "name": "Instructed currency code", "description": "Alphabetic currency code of the instructed amount, referenced from the governed currency registry.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-006" ] }, { "id": "currency-minor-unit", "name": "Currency minor unit", "description": "Number of decimal places governed by the currency registry, used to validate amount scale; carried by reference to registry version, not copied as truth.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "settlement-amount", "name": "Settlement amount", "description": "Amount actually moved between agents at settlement, which may differ from the instructed amount.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "A monetary amount is a value object with no independent retrieval identity: it exists only inside an instruction, settlement record, charge breakdown, advice or posting, and is never separately created, versioned or addressed. Promoting it to an artifact would duplicate the amount in every carrier and create reconciliation ambiguity about which copy is authoritative." }, { "id": "currency-conversion-and-exchange-rate", "name": "Currency conversion and exchange rate application", "description": "When the payer's currency differs from the payee's, a rate is applied by an identified party at an identified moment, and the resulting equivalent amount and any spread must be attributable. The rate is provenance-bearing data: which quoting source, which quotation time, which rate type and whether it is contractual or indicative all change the payer's position.", "source_refs": [ "SRC-009", "SRC-006", "SRC-012", "SRC-001" ], "questions": [ { "id": "q-rate-provenance", "text": "Which party applied the exchange rate, from which quoting source, and at what quotation time?", "kind": "provenance", "answer_data": [ "Conversion party reference", "Rate source name", "Quotation timestamp", "Rate type (contractual, indicative, scheme)" ] }, { "id": "q-rate-disclosure", "text": "Was the applicable rate disclosed to the payer before the order became irrevocable?", "kind": "authority", "answer_data": [ "Disclosure made (boolean)", "Disclosure timestamp", "Disclosed rate value", "Disclosure channel" ] }, { "id": "q-conversion-spread", "text": "What margin separates the applied rate from the reference rate, and how is it attributed?", "kind": "measurement", "answer_data": [ "Applied rate", "Reference rate", "Margin value or percentage", "Margin-receiving party reference" ] } ], "data_elements": [ { "id": "exchange-rate-value", "name": "Exchange rate value", "description": "Rate applied to convert between the source and target currency of the payment.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-012" ] }, { "id": "rate-quotation-time", "name": "Rate quotation time", "description": "Moment at which the applied rate was quoted, distinct from the moment of conversion.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "conversion-party-reference", "name": "Conversion party reference", "description": "Reference to the party that performed the currency conversion.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-012" ] } ], "artifacts": [ { "id": "exchange-rate-quote-record", "name": "Exchange rate quote record", "description": "An immutable record of one rate quotation used for a payment, capturing base and quote currency, rate value, rate type, quoting source, quotation time and the validity window during which the quote could be applied.", "media_or_form": [ "immutable record", "quote receipt", "structured data row" ], "serial": false, "identity_strategy": "Identified by the quoting source's own quote identifier where available; otherwise by a Dimension-assigned ULID, never by the quotation date alone.", "source_refs": [ "SRC-009", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "charges-fees-and-charge-bearer", "name": "Charges, fees and charge-bearer allocation", "description": "Charge bearer codes determine whether the payer, the payee, or both share the cost of a transfer, and whether charges may be deducted from the principal. Where a receiving agent deducts charges, the legal effect on the underlying obligation may still be that the full instructed amount was paid, so the accounting of charges and the accounting of discharge diverge and both must be represented.", "source_refs": [ "SRC-012", "SRC-005", "SRC-003", "SRC-001" ], "questions": [ { "id": "q-charge-bearer-allocation", "text": "Which charge bearer arrangement applies, and does it permit deduction from the transferred principal?", "kind": "ownership", "answer_data": [ "Charge bearer code", "Deduction permitted (boolean)", "Governing rule reference" ] }, { "id": "q-charge-attribution", "text": "Which agent levied each charge, in what amount and currency, and on which leg?", "kind": "measurement", "answer_data": [ "Charging agent reference", "Charge amount", "Charge currency", "Leg identifier" ] }, { "id": "q-charge-discharge-effect", "text": "If charges were deducted in transit, is the underlying obligation still treated as discharged in the full instructed amount?", "kind": "exception", "answer_data": [ "Deducted total", "Discharge treatment code", "Beneficiary demand raised (boolean)", "Originator response" ] } ], "data_elements": [ { "id": "charge-bearer-code", "name": "Charge bearer code", "description": "Code allocating transfer costs between payer and payee, such as shared, creditor-borne, debtor-borne or service-level defined.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "charge-amount", "name": "Charge amount", "description": "Amount of one charge levied on the payment by an identified agent.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-005" ] }, { "id": "charging-agent-reference", "name": "Charging agent reference", "description": "Reference to the agent that levied a specific charge.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "charge-breakdown-statement", "name": "Charge breakdown statement", "description": "An itemised statement of every charge applied to a payment showing the levying agent, amount, currency, leg, and whether it was deducted from principal or billed separately, sufficient to reconcile instructed amount to received amount.", "media_or_form": [ "itemised statement", "structured record set", "advice attachment" ], "serial": false, "identity_strategy": "Keyed by the payment's authoritative master identifier; superseded in place when a later leg reports additional charges, with prior versions retained under the patch rules.", "source_refs": [ "SRC-012", "SRC-005" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "parties-accounts-and-instruments", "name": "Parties, Accounts and Instruments", "description": "Who is paying whom, through which chain of agents, against which account references, and using which payment instrument or credential.", "rationale": "Statutory definitions build the payment around payer, payee and payment service provider; funds-transfer law adds sender, receiving bank, beneficiary and beneficiary's bank. Operator rules require structured party data to travel with the payment, and misdescription of an account identifier has explicit legal consequences, so party and account references are load-bearing rather than descriptive.", "source_refs": [ "SRC-001", "SRC-004", "SRC-012", "SRC-002", "SRC-014" ], "layers": [ { "id": "parties-and-roles", "name": "Parties and Roles", "description": "The role structure of a payment and the party data that must accompany it across the agent chain.", "source_refs": [ "SRC-001", "SRC-004", "SRC-012" ], "findings": [ { "id": "payer-payee-and-agent-roles", "name": "Payer, payee and the ordered agent chain", "description": "Roles are defined functionally, not by entity type: the payer initiates or consents, the payee is the intended recipient of funds, and a chain of agents (debtor agent, intermediaries, creditor agent) carries the instruction. Funds-transfer law adds that each hop has its own sender and receiving bank, so a single payment contains several nested instruction relationships. Initiating party and ultimate debtor or creditor may differ from payer and payee.", "source_refs": [ "SRC-001", "SRC-004", "SRC-012" ], "questions": [ { "id": "q-role-occupancy", "text": "Which entity occupies each payment role, and does any entity occupy more than one role?", "kind": "relationship", "answer_data": [ "Role code", "Entity reference", "Role overlap flag" ] }, { "id": "q-ultimate-parties", "text": "Do the ultimate debtor or ultimate creditor differ from the account-holding payer and payee, and why?", "kind": "composition", "answer_data": [ "Ultimate debtor reference", "Ultimate creditor reference", "Divergence reason", "On-behalf-of arrangement reference" ] }, { "id": "q-agent-chain-order", "text": "What is the ordered sequence of agents, and which agent is the sender and receiving bank on each hop?", "kind": "composition", "answer_data": [ "Hop index", "Sending agent reference", "Receiving agent reference", "Hop instruction reference" ] }, { "id": "q-role-authority", "text": "On what authority does the initiating party act where it is not the payer itself?", "kind": "authority", "answer_data": [ "Authority basis code", "Mandate or power reference", "Authority validity window" ] } ], "data_elements": [ { "id": "payer-role-reference", "name": "Payer role reference", "description": "Reference to the entity holding the payer role, resolved to a person or organization model rather than inlined.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-004" ] }, { "id": "payee-role-reference", "name": "Payee role reference", "description": "Reference to the entity that is the intended recipient of the funds.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-004" ] }, { "id": "agent-chain", "name": "Agent chain", "description": "Ordered collection of agent roles carrying the payment, each with a hop index and a role code.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-004" ] }, { "id": "initiating-party-reference", "name": "Initiating party reference", "description": "Reference to the party that submitted the instruction where it differs from the payer.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Parties are never materialised as artifacts inside this model. Natural persons and organizations are governed by sibling entity models with their own identity, stewardship and retention rules; duplicating them here would create competing masters and would import personal-data obligations that belong to the party models. Only role assignments and references are held, and they exist solely as structure on the payment aggregate." }, { "id": "party-data-carried-with-the-payment", "name": "Party data carried with the payment", "description": "Rails impose minimum structured party data. Operator rules require structured postal address content including at least country code and town name for parties and agents, and encourage account information inside the corresponding party element for straight-through processing. This data is simultaneously an interoperability requirement and a personal-data exposure, and its completeness materially affects settlement success and screening outcomes.", "source_refs": [ "SRC-012", "SRC-011", "SRC-001", "SRC-014" ], "questions": [ { "id": "q-minimum-party-data", "text": "What is the minimum party data set the selected rail requires, and is every mandatory element present?", "kind": "requirement", "answer_data": [ "Required element list", "Present element list", "Missing element list", "Rail rule reference" ] }, { "id": "q-address-structure", "text": "Is the party address supplied in structured form, and which structured components are populated?", "kind": "validation", "answer_data": [ "Structured address flag", "Country code", "Town name", "Other populated components" ] }, { "id": "q-party-data-minimisation", "text": "Which carried party attributes exceed what the rail requires, and on what basis are they transmitted?", "kind": "privacy", "answer_data": [ "Excess attribute list", "Transmission basis", "Recipient scope", "Suppression option available (boolean)" ] }, { "id": "q-party-identifier-scheme", "text": "Which identifier scheme is used to identify each party, and is the scheme externally governed?", "kind": "interoperability", "answer_data": [ "Identifier scheme name", "Identifier value", "Scheme governance body", "Scheme version" ] } ], "data_elements": [ { "id": "party-name", "name": "Party name", "description": "Name of a payment party as carried in the instruction, which may be a display form rather than a legal name.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "structured-postal-address", "name": "Structured postal address", "description": "Structured address components for a party or agent, with country code and town name mandatory on some rails.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "party-identifier-scheme-code", "name": "Party identifier scheme code", "description": "Code naming the externally governed scheme under which a party identifier is issued.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-011" ] } ], "artifacts": [ { "id": "party-data-payload-profile", "name": "Party data payload profile", "description": "A per-rail profile stating which party and agent attributes are mandatory, optional or prohibited, their structural form, and the data-protection classification of each, used to validate outbound instructions and to drive minimisation before transmission.", "media_or_form": [ "validation profile", "field mapping table", "policy binding" ], "serial": true, "identity_strategy": "Identified by rail identifier plus profile version; superseded profiles are retained so that historic instructions can be revalidated against the rules in force when they were sent.", "source_refs": [ "SRC-012", "SRC-011", "SRC-014" ] } ], "inline_only_rationale": null } ] }, { "id": "accounts-and-instruments", "name": "Account References and Instruments", "description": "The account identifiers a payment is directed at, and the instrument or credential used to initiate it.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005", "SRC-014" ], "findings": [ { "id": "account-reference-and-unique-identifier", "name": "Account references and the unique identifier rule", "description": "A unique identifier is the combination of letters, numbers or symbols a provider specifies to identify a user or their account unambiguously. Where a payer supplies an incorrect unique identifier, the provider is generally not liable for the misdirected payment but must make reasonable efforts to recover the funds; funds-transfer law reaches a comparable result through misdescription rules. This makes identifier correctness a legally significant field rather than a data-quality nicety.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005", "SRC-012" ], "questions": [ { "id": "q-unique-identifier-designation", "text": "Which supplied value is designated as the unique identifier by the provider, and which other account data is advisory only?", "kind": "identity", "answer_data": [ "Unique identifier value", "Identifier scheme", "Advisory field list", "Designating provider reference" ] }, { "id": "q-identifier-mismatch", "text": "What happens when the account name and the unique identifier disagree, and who bears the resulting loss?", "kind": "exception", "answer_data": [ "Mismatch detected (boolean)", "Verification result code", "Liability allocation", "Recovery effort record reference" ] }, { "id": "q-identifier-validation-depth", "text": "Was the identifier only structurally validated, or was existence and ownership confirmed with the receiving institution?", "kind": "validation", "answer_data": [ "Validation level code", "Validating party reference", "Validation timestamp", "Validation outcome" ] } ], "data_elements": [ { "id": "debtor-account-identifier", "name": "Debtor account identifier", "description": "Identifier of the account to be debited, expressed under a named identifier scheme.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-012" ] }, { "id": "creditor-account-identifier", "name": "Creditor account identifier", "description": "Identifier of the account to be credited, treated as the unique identifier where the provider so designates.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "account-identifier-scheme", "name": "Account identifier scheme", "description": "Named scheme under which an account identifier is issued and validated.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-011" ] }, { "id": "identifier-verification-result", "name": "Identifier verification result", "description": "Outcome of any check that the identifier resolves to the named payee, including partial-match results.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "account-identifier-validation-report", "name": "Account identifier validation report", "description": "A dated record of the checks applied to the account identifiers of one payment: structural validation, scheme check-digit validation, reachability lookup and any payee-name confirmation, with each result attributed to the party that performed it.", "media_or_form": [ "validation report", "structured record", "audit entry" ], "serial": false, "identity_strategy": "Keyed by the payment's authoritative master identifier plus the validating party; re-validation appends a new result rather than overwriting, so the state known at instruction time remains reconstructible.", "source_refs": [ "SRC-002", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "payment-instrument-and-credential", "name": "Payment instrument and credential handling", "description": "A payment instrument is a personalised device or an agreed personalised set of procedures used to initiate payment orders. Its credential may be a card number, a token, a mandate reference or an authentication factor set. Where cardholder data and sensitive authentication data are involved, an external security standard governs storage, transmission and the population of systems in scope, constraining what this model may hold at all.", "source_refs": [ "SRC-001", "SRC-014", "SRC-006" ], "questions": [ { "id": "q-instrument-definition", "text": "Which device or agreed procedure constitutes the payment instrument used here, and who issued it?", "kind": "definition", "answer_data": [ "Instrument type code", "Issuing provider reference", "Instrument reference or token", "Personalisation basis" ] }, { "id": "q-credential-storage-limits", "text": "Which credential elements may be stored after authorisation, and which must never be retained?", "kind": "security", "answer_data": [ "Storable element list", "Prohibited element list", "Protection method applied", "Governing standard reference" ] }, { "id": "q-instrument-lifecycle-state", "text": "What is the current state of the instrument, and does its expiry or suspension invalidate pending payments?", "kind": "lifecycle", "answer_data": [ "Instrument state code", "State effective time", "Effect on pending payments", "Replacement instrument reference" ] }, { "id": "q-credential-access-scope", "text": "Which roles may resolve a stored token back to the underlying credential, and under what control?", "kind": "access", "answer_data": [ "Authorised role list", "Detokenisation control", "Approval requirement", "Access log reference" ] } ], "data_elements": [ { "id": "instrument-type-code", "name": "Instrument type code", "description": "Type of payment instrument used to initiate the payment order.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "instrument-token-reference", "name": "Instrument token reference", "description": "Non-sensitive surrogate reference standing for the instrument credential; the credential itself is held outside this model where security standards require.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "mandate-reference", "name": "Mandate reference", "description": "Reference to the standing authorisation under which a payee-initiated payment may be collected.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] } ], "artifacts": [ { "id": "instrument-credential-record", "name": "Instrument credential record", "description": "A protected record binding an instrument token to its type, issuer, state and permitted uses, deliberately excluding sensitive authentication data and holding only truncated or otherwise protected representations of the underlying account number.", "media_or_form": [ "protected record", "vault entry", "reference descriptor" ], "serial": false, "identity_strategy": "Identified by the issuer's own instrument identifier where the adopting Dimension is the issuer; otherwise by the surrogate token issued by the credential vault, never by the raw credential value.", "source_refs": [ "SRC-014", "SRC-001" ] } ], "inline_only_rationale": null }, { "id": "account-alias-and-proxy-resolution", "name": "Account, unique identifier and proxy references", "description": "PSD2 uses a unique identifier specified by the PSP to identify unambiguously another payment service user or that user's payment account. ISO 20022 and EPC SCT carry IBAN or other account identification and, in the 2025 SCT rulebook, alias and proxy definitions. Account containers and balances as holdings belong to the monetary-instrument sibling; this model stores only the reference used to debit or credit. Name-versus-number mismatch is an execution rule (UCC 4A), not a reason to inline account masters.", "source_refs": [ "SRC-019", "SRC-016", "SRC-021", "SRC-020" ], "inline_only_rationale": null, "data_elements": [ { "id": "account-alias-and-proxy-resolution-data01", "name": "payer_account_ref", "description": "Reference to the account to be debited, held in the sibling monetary-instrument model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-016", "SRC-021", "SRC-020" ] }, { "id": "account-alias-and-proxy-resolution-data02", "name": "payee_account_ref", "description": "Reference to the account to be credited, held in the sibling monetary-instrument model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-016", "SRC-021", "SRC-020" ] }, { "id": "account-alias-and-proxy-resolution-data03", "name": "payer_unique_identifier", "description": "Unique identifier specified by the PSP that identifies the payer's payment account.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-016", "SRC-021", "SRC-020" ] }, { "id": "account-alias-and-proxy-resolution-data04", "name": "payee_unique_identifier", "description": "Unique identifier specified by the PSP that identifies the payee's payment account.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-016", "SRC-021", "SRC-020" ] }, { "id": "account-alias-and-proxy-resolution-data05", "name": "payer_proxy_type", "description": "Type of alias or proxy submitted for the payer.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-016", "SRC-021", "SRC-020" ] }, { "id": "account-alias-and-proxy-resolution-data06", "name": "payer_proxy_value", "description": "Alias or proxy value submitted for the payer.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-016", "SRC-021", "SRC-020" ] }, { "id": "account-alias-and-proxy-resolution-data07", "name": "payee_proxy_type", "description": "Type of alias or proxy submitted for the payee.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-016", "SRC-021", "SRC-020" ] }, { "id": "account-alias-and-proxy-resolution-data08", "name": "payee_proxy_value", "description": "Alias or proxy value submitted for the payee.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-016", "SRC-021", "SRC-020" ] }, { "id": "account-alias-and-proxy-resolution-data09", "name": "account_scheme", "description": "Account identification scheme used, such as IBAN or a national account scheme.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-016", "SRC-021", "SRC-020" ] } ], "artifacts": [ { "id": "account-alias-and-proxy-resolution-artifact01", "name": "EPC 2025 SCT rulebook alias and proxy definitions and account identification practice", "description": "Scheme rulebook clauses defining aliases and proxies and how accounts are identified for SEPA credit transfers.", "media_or_form": [ "Scheme rulebook (PDF)" ], "serial": false, "identity_strategy": "Identified by rulebook version, effective period and clause number.", "source_refs": [ "SRC-021" ] } ], "questions": [ { "id": "account-alias-and-proxy-resolution-q01", "text": "What unique identifier, IBAN or other account scheme identifier was used to identify the payer account to debit and the payee account to credit?", "kind": "identity", "answer_data": [ "payer_unique_identifier (string)", "payee_unique_identifier (string)", "account_scheme (enum)", "payer_account_ref (account-ref)", "payee_account_ref (account-ref)" ] }, { "id": "account-alias-and-proxy-resolution-q02", "text": "If an alias or proxy (mobile number, email, PayID, VPA or similar) was used, what type and value were submitted and to which account identifier did the scheme resolve them?", "kind": "interoperability", "answer_data": [ "payee_proxy_type (enum)", "payee_proxy_value (string)", "resolved_account_identifier (string)", "resolution_service (string)" ] }, { "id": "account-alias-and-proxy-resolution-q03", "text": "Did the instructed name and account identifier identify the same person, and if they diverged, which identifier was the receiving bank obliged or permitted to rely on?", "kind": "constraint", "answer_data": [ "name_number_match_status (enum)", "relied_on_identifier (enum)", "mismatch_handling_rule (string)" ] } ] }, { "id": "verification-of-payee", "name": "Verification of payee", "description": "EPC SCT implementation and EU instant-transfer amendments introduce payee verification / confirmation-of-payee so that a payer can check alignment between the unique identifier and the payee name before execution. FATF Recommendation 16 revisions add obligations on beneficiary institutions to check alignment of beneficiary information in payment messages. These checks are payment-process quality controls; they do not replace party master KYC. Absence of a global primary standard for proxy resolution is a recorded gap outside IBAN-name matching.", "source_refs": [ "SRC-024", "SRC-022", "SRC-021" ], "inline_only_rationale": null, "data_elements": [ { "id": "verification-of-payee-data01", "name": "vop_performed", "description": "Whether payee verification was carried out before execution.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-022", "SRC-021" ] }, { "id": "verification-of-payee-data02", "name": "vop_result", "description": "Match, close-match or mismatch result returned.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-022", "SRC-021" ] }, { "id": "verification-of-payee-data03", "name": "vop_matched_name", "description": "Name returned by the verification service.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-022", "SRC-021" ] }, { "id": "verification-of-payee-data04", "name": "vop_checked_at", "description": "Instant the verification was performed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-022", "SRC-021" ] }, { "id": "verification-of-payee-data05", "name": "payer_proceeded_despite_mismatch", "description": "Whether the payer chose to proceed after a non-match.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-022", "SRC-021" ] }, { "id": "verification-of-payee-data06", "name": "vop_service_id", "description": "Identifier of the directory or scheme service that returned the match.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-022", "SRC-021" ] } ], "artifacts": [ { "id": "verification-of-payee-artifact01", "name": "EU instant credit-transfer payee-verification overlay on Regulation 260/2012 as amended", "description": "Legislative overlay requiring a check of alignment between the payee's unique identifier and name before execution.", "media_or_form": [ "Consolidated legislative text (EUR-Lex HTML)" ], "serial": false, "identity_strategy": "Identified by CELEX number, consolidation date and article reference.", "source_refs": [ "SRC-024" ] } ], "questions": [ { "id": "verification-of-payee-q01", "text": "Was verification of payee or confirmation of payee performed, what match result was returned, and at what event time?", "kind": "evidence", "answer_data": [ "vop_performed (boolean)", "vop_result (enum)", "vop_checked_at (rfc3339)", "vop_service_id (string)" ] }, { "id": "verification-of-payee-q02", "text": "If the check was a mismatch or close match, did the payer explicitly proceed, and was that choice recorded as an exception to straight-through processing?", "kind": "exception", "answer_data": [ "payer_proceeded_despite_mismatch (boolean)", "payer_confirmation_at (rfc3339)", "stp_exception_code (string)" ] }, { "id": "verification-of-payee-q03", "text": "Which directory or scheme API provided the match, and can the result be reused across rails or only within this scheme?", "kind": "interoperability", "answer_data": [ "vop_service_id (string)", "result_portability (enum)" ] } ] } ] } ] }, { "id": "consent-authorisation-and-instruction", "name": "Consent, Authorisation and Instruction Control", "description": "What makes a payment authorised, how the order is received and accepted or refused, and until what moment the payer can still stop it.", "rationale": "Statutory rules make authorisation, the time of receipt, refusal with reasons and the point of irrevocability determinative of liability. Funds-transfer law separately conditions an instruction's status as a payment order on the absence of conditions and on a defined reimbursement path, so the control surface of a payment is normative rather than a matter of implementation convenience.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-013" ], "layers": [ { "id": "consent-and-authorisation", "name": "Consent and Authorisation", "description": "The consent record, authentication evidence and the acceptance or refusal decision, including screening holds.", "source_refs": [ "SRC-001", "SRC-002", "SRC-013" ], "findings": [ { "id": "authorisation-and-consent-evidence", "name": "Authorisation state and consent evidence", "description": "A payment is authorised only if the payer consented in the agreed form. When a user disputes authorisation, the provider must be able to evidence authentication, and consumer rules cap payer liability and set notification windows beyond which claims lapse. The evidence set, not the assertion, is what survives challenge, so authentication method, timing and outcome must be retained separately from the payment body.", "source_refs": [ "SRC-001", "SRC-002", "SRC-013" ], "questions": [ { "id": "q-consent-form", "text": "In what agreed form was consent given, and does that form cover this specific payment or a series?", "kind": "authority", "answer_data": [ "Consent form code", "Consent scope (single, recurring, series)", "Consenting party reference", "Consent timestamp" ] }, { "id": "q-authentication-evidence", "text": "What authentication evidence exists to show the payer authorised this payment, and where is it retained?", "kind": "evidence", "answer_data": [ "Authentication method code", "Authentication outcome", "Evidence artifact reference", "Retention location" ] }, { "id": "q-claim-window", "text": "Within what period may the payer still claim the payment was unauthorised, and when does that period start?", "kind": "temporal", "answer_data": [ "Claim window duration", "Window start event", "Window start timestamp", "Governing rule reference" ] } ], "data_elements": [ { "id": "authorisation-state", "name": "Authorisation state", "description": "Whether the payment is authorised, unauthorised, or contested pending investigation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "consent-timestamp", "name": "Consent timestamp", "description": "Moment at which the payer gave consent in the agreed form.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "authentication-method-code", "name": "Authentication method code", "description": "Method or combination of factors used to authenticate the payer for this payment.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-013" ] } ], "artifacts": [ { "id": "authorisation-evidence-record", "name": "Authorisation evidence record", "description": "A tamper-evident record of the consent and authentication events for one payment, capturing method, factors exercised, outcome, device or channel context and timing, sufficient to answer an unauthorised-transaction claim within the statutory window.", "media_or_form": [ "tamper-evident log entry", "signed record", "evidence pack" ], "serial": false, "identity_strategy": "Keyed by the payment's authoritative master identifier plus the authorisation attempt sequence; append-only, so failed attempts remain visible alongside the successful one.", "source_refs": [ "SRC-002", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "risk-screening-and-acceptance-decision", "name": "Risk screening, holds and the acceptance decision", "description": "A provider may refuse a payment order but must notify the user at the earliest opportunity and within the applicable execution period, give reasons where lawful, and explain how to correct factual errors. Refusal, hold and decline are distinct outcomes with distinct downstream obligations, and screening holds may be legally required to be non-disclosed, which conflicts with the general duty to give reasons.", "source_refs": [ "SRC-002", "SRC-012", "SRC-015", "SRC-014" ], "questions": [ { "id": "q-decision-outcome", "text": "Was the order accepted, refused, held or declined, and which of these did the payer actually experience?", "kind": "decision", "answer_data": [ "Decision outcome code", "Decision timestamp", "Deciding participant reference", "User-visible outcome" ] }, { "id": "q-refusal-notification", "text": "Was refusal notified within the applicable execution period, with reasons and correction instructions?", "kind": "process", "answer_data": [ "Notification timestamp", "Reason given (boolean)", "Reason text or code", "Correction guidance provided (boolean)" ] }, { "id": "q-screening-hold-disclosure", "text": "Where a screening hold prevents disclosure of the true reason, how is the tension with the duty to give reasons resolved?", "kind": "exception", "answer_data": [ "Non-disclosure basis reference", "Substitute message given", "Internal true reason code", "Approving role" ] } ], "data_elements": [ { "id": "acceptance-decision-code", "name": "Acceptance decision code", "description": "Outcome of the provider's decision on the payment order: accepted, refused, held or declined.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-012" ] }, { "id": "decline-or-refusal-reason-code", "name": "Decline or refusal reason code", "description": "Coded reason for refusal or decline, which may differ from the reason disclosed to the user.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-012" ] }, { "id": "screening-hold-state", "name": "Screening hold state", "description": "Whether the payment is held pending sanctions, fraud or compliance review, and the state of that review.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015", "SRC-014" ] } ], "artifacts": [ { "id": "screening-decision-log", "name": "Screening and decision log", "description": "An append-only log of every automated and manual check applied to a payment before acceptance, recording rule or list version, match details, disposition, reviewing role and timing, retained under compliance record-keeping duties.", "media_or_form": [ "append-only log", "case note set", "structured audit trail" ], "serial": false, "identity_strategy": "Keyed by the payment's authoritative master identifier plus check sequence; entries are immutable and dispositions are recorded as new entries rather than edits.", "source_refs": [ "SRC-002", "SRC-015", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "mandate-and-request-to-pay", "name": "Mandate and request-to-pay", "description": "Direct debits depend on preauthorisation. ISO 20022 payments-mandate messages (pain.009 mandate initiation, pain.010 amendment) and pain.008 customer direct-debit initiation implement that authority as a reusable mandate distinct from each resulting payment. Creditor payment activation / request-to-pay (pain.013/pain.014) asks the payer to initiate a credit transfer rather than pulling funds. EPC SCT rulebooks additionally specify recall initiation and status-update handling, which are exception processes on an already initiated credit transfer, not a mandate. A mandate is not the invoice and not the payment.", "source_refs": [ "SRC-016", "SRC-026", "SRC-021" ], "inline_only_rationale": null, "data_elements": [ { "id": "mandate-and-request-to-pay-data01", "name": "mandate_id", "description": "Identifier of the mandate authorising debits.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-026", "SRC-021" ] }, { "id": "mandate-and-request-to-pay-data02", "name": "mandate_type", "description": "Type of standing authority relied on.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-026", "SRC-021" ] }, { "id": "mandate-and-request-to-pay-data03", "name": "mandate_status", "description": "Current status of the mandate.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-026", "SRC-021" ] }, { "id": "mandate-and-request-to-pay-data04", "name": "mandate_signed_at", "description": "Instant the mandate was signed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-026", "SRC-021" ] }, { "id": "mandate-and-request-to-pay-data05", "name": "mandate_expires_at", "description": "Instant the mandate expires.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-026", "SRC-021" ] }, { "id": "mandate-and-request-to-pay-data06", "name": "sequence_type", "description": "Whether this occurrence is first, recurrent, one-off or final.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-026", "SRC-021" ] }, { "id": "mandate-and-request-to-pay-data07", "name": "request_to_pay_id", "description": "Identifier of the creditor payment activation request.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-026", "SRC-021" ] }, { "id": "mandate-and-request-to-pay-data08", "name": "request_to_pay_status", "description": "Status reported for the request to pay.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-026", "SRC-021" ] }, { "id": "mandate-and-request-to-pay-data09", "name": "max_amount", "description": "Maximum amount the mandate permits.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-026", "SRC-021" ] } ], "artifacts": [ { "id": "mandate-and-request-to-pay-artifact01", "name": "ISO 20022 mandate initiation and amendment (pain.009/pain.010) and direct-debit initiation (pain.008)", "description": "Mandate and direct-debit initiation message instances carrying standing authority separately from each resulting payment.", "media_or_form": [ "ISO 20022 XML message instance" ], "serial": true, "identity_strategy": "Identified by mandate identification, with amendments referencing the original mandate identifier.", "source_refs": [ "SRC-016" ] }, { "id": "mandate-and-request-to-pay-artifact02", "name": "ISO 20022 Creditor Payment Activation Request (pain.013) and status report (pain.014)", "description": "Request-to-pay message instances asking the payer to initiate a credit transfer and reporting the request status.", "media_or_form": [ "ISO 20022 XML message instance" ], "serial": true, "identity_strategy": "Identified by the request identification and correlated to any payment created in response.", "source_refs": [ "SRC-016" ] } ], "questions": [ { "id": "mandate-and-request-to-pay-q01", "text": "Does a direct-debit or other pull mandate authorize this payment, what is its identifier and status, and is this occurrence first, recurrent or last?", "kind": "lifecycle", "answer_data": [ "mandate_id (string)", "mandate_status (enum)", "sequence_type (enum)", "mandate_signed_at (rfc3339)" ] }, { "id": "mandate-and-request-to-pay-q02", "text": "What maximum amount, creditor, account and expiry bound the mandate, and did this payment stay inside those bounds?", "kind": "constraint", "answer_data": [ "max_amount (decimal)", "mandate_creditor_ref (party-ref)", "mandate_expires_at (rfc3339)", "within_mandate_bounds (boolean)" ] }, { "id": "mandate-and-request-to-pay-q03", "text": "If a request-to-pay or creditor payment activation preceded this credit transfer, what is its identifier and status, and which payment was created in response?", "kind": "process", "answer_data": [ "request_to_pay_id (string)", "request_to_pay_status (enum)", "resulting_payment_ref (payment-ref)" ] } ] } ] }, { "id": "order-receipt-and-revocability", "name": "Order Receipt and Revocability", "description": "When the order counts as received, how business days and cut-offs shift that moment, and the point beyond which the payer can no longer stop the payment.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-010" ], "findings": [ { "id": "order-receipt-and-cut-off", "name": "Time of receipt, cut-off and business day", "description": "Receipt occurs when the order reaches the provider's system, but an order received outside business hours or after a cut-off is deemed received on the next business day, and the parties may agree that execution starts on a specified date or when funds become available. Because every execution deadline is measured from the time of receipt, receipt is the temporal origin of the whole aggregate and must be recorded as an actual and a deemed value.", "source_refs": [ "SRC-002", "SRC-003", "SRC-010", "SRC-004" ], "questions": [ { "id": "q-actual-versus-deemed-receipt", "text": "What is the actual time the order reached the provider, and what is the deemed time of receipt after cut-off rules?", "kind": "temporal", "answer_data": [ "Actual receipt timestamp", "Deemed receipt timestamp", "Cut-off rule applied", "Business day calendar reference" ] }, { "id": "q-requested-execution-date", "text": "Did the parties agree a future execution date or a funds-availability trigger instead of immediate execution?", "kind": "process", "answer_data": [ "Requested execution date", "Trigger condition", "Agreement reference" ] }, { "id": "q-calendar-authority", "text": "Whose business-day calendar governs, and how are divergent calendars across the agent chain reconciled?", "kind": "constraint", "answer_data": [ "Governing calendar owner", "Closing days list", "Divergence handling rule", "Affected hop identifiers" ] } ], "data_elements": [ { "id": "actual-receipt-timestamp", "name": "Actual receipt timestamp", "description": "Moment the payment order physically reached the receiving provider's systems.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "deemed-receipt-timestamp", "name": "Deemed receipt timestamp", "description": "Legally effective time of receipt after applying cut-off and business-day rules, from which execution deadlines run.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "requested-execution-date", "name": "Requested execution date", "description": "Date on which the parties agreed execution should begin, where later than receipt.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "business-day-calendar-reference", "name": "Business day calendar reference", "description": "Reference to the operating calendar of the governing rail or provider, including closing days.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-003" ] } ], "artifacts": [ { "id": "order-receipt-acknowledgement", "name": "Order receipt acknowledgement", "description": "The record returned to the initiating party confirming that an order was received, stating the actual and deemed receipt times, the calendar applied and the resulting execution deadline.", "media_or_form": [ "acknowledgement record", "status response", "receipt document" ], "serial": false, "identity_strategy": "Keyed by the payment's authoritative master identifier; issued once per accepted submission, with resubmissions generating distinct acknowledgements linked to the same payment.", "source_refs": [ "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "revocation-amendment-and-irrevocability", "name": "Revocation, amendment and irrevocability", "description": "As a rule the payer cannot revoke an order after submission, but scheme-specific exceptions exist: direct debits may typically be revoked until the end of the business day before the agreed debit day, and payee-initiated orders lose revocability once consent is given to the payee. After irrevocability, the only remaining lever is a request for return or recall addressed to the receiving side, which the receiver may refuse.", "source_refs": [ "SRC-002", "SRC-004", "SRC-012" ], "questions": [ { "id": "q-irrevocability-point", "text": "At what precise moment does this payment become irrevocable, and what rule fixes that moment?", "kind": "lifecycle", "answer_data": [ "Irrevocability timestamp", "Fixing rule reference", "Rule source (statute, scheme, system)" ] }, { "id": "q-revocation-window", "text": "Is a scheme-specific revocation window still open, and who must consent to a late revocation?", "kind": "constraint", "answer_data": [ "Window open (boolean)", "Window end timestamp", "Consenting parties required", "Charge for late revocation" ] }, { "id": "q-post-irrevocability-remedy", "text": "Once irrevocable, what recall or return request may be raised and what is the receiver obliged to do?", "kind": "event", "answer_data": [ "Request type", "Request reference", "Receiver obligation", "Response deadline" ] }, { "id": "q-amendment-scope", "text": "Which fields of an accepted order may be amended without cancelling and reissuing it?", "kind": "constraint", "answer_data": [ "Amendable field list", "Amendment mechanism", "Approval requirement", "Resulting new reference" ] } ], "data_elements": [ { "id": "revocability-state", "name": "Revocability state", "description": "Whether the payment is still revocable by the payer, revocable only with counterparty consent, or irrevocable.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "irrevocability-timestamp", "name": "Irrevocability timestamp", "description": "Moment from which the payer can no longer unilaterally revoke the order.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "cancellation-request-reference", "name": "Cancellation request reference", "description": "Reference to a cancellation, recall or return request raised against the payment.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-004" ] } ], "artifacts": [ { "id": "cancellation-request-record", "name": "Cancellation or recall request record", "description": "A record of a request to cancel, recall or return a payment, capturing the requesting party, the reason code, the original payment reference, the response received and whether funds were actually returned.", "media_or_form": [ "request and response pair", "case record", "message exchange log" ], "serial": false, "identity_strategy": "Identified by the scheme's own recall or cancellation case reference where one is assigned; otherwise by a Dimension-assigned ULID linked to the original payment identifier.", "source_refs": [ "SRC-012", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "payment-order-as-instruction", "name": "Payment order as instruction", "description": "UCC § 4A-103 defines a payment order as an instruction of a sender to a receiving bank to pay, or cause another bank to pay, a fixed or determinable amount of money to a beneficiary, without a condition to payment other than time of payment; the order is issued when sent to the receiving bank. PSD2 defines a payment order as an instruction by a payer or payee to its PSP requesting execution of a payment transaction, and a payment instrument as a personalised device or set of procedures used to initiate a payment order. ISO 20022 pain.001 is the customer credit-transfer initiation; pain.008 is customer direct-debit initiation. A batch file may contain many payment orders; each credit transfer in a bulk is a separate payment.", "source_refs": [ "SRC-020", "SRC-019", "SRC-016", "SRC-026" ], "inline_only_rationale": null, "data_elements": [ { "id": "payment-order-as-instruction-data01", "name": "payment_order_id", "description": "Identifier of the payment order, distinct from the later interbank transaction.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-019", "SRC-016", "SRC-026" ] }, { "id": "payment-order-as-instruction-data02", "name": "sender_party_ref", "description": "Party that sent the order to the receiving bank.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-019", "SRC-016", "SRC-026" ] }, { "id": "payment-order-as-instruction-data03", "name": "receiving_bank_ref", "description": "Bank that received the order.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-019", "SRC-016", "SRC-026" ] }, { "id": "payment-order-as-instruction-data04", "name": "issued_at", "description": "Instant the order was sent to the receiving bank.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-019", "SRC-016", "SRC-026" ] }, { "id": "payment-order-as-instruction-data05", "name": "requested_execution_date", "description": "Business date the sender requested for execution.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-019", "SRC-016", "SRC-026" ] }, { "id": "payment-order-as-instruction-data06", "name": "initiation_channel", "description": "Channel through which the order was initiated.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-019", "SRC-016", "SRC-026" ] }, { "id": "payment-order-as-instruction-data07", "name": "payment_instrument_ref", "description": "Personalised device or set of procedures used to initiate the order.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-019", "SRC-016", "SRC-026" ] }, { "id": "payment-order-as-instruction-data08", "name": "batch_or_group_id", "description": "Identifier of the batch or group file that carried this order among others.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-019", "SRC-016", "SRC-026" ] }, { "id": "payment-order-as-instruction-data09", "name": "received_at_psp", "description": "Instant the receiving PSP took receipt of the order.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-019", "SRC-016", "SRC-026" ] } ], "artifacts": [ { "id": "payment-order-as-instruction-artifact01", "name": "UCC § 4A-103 payment-order definition and issuance", "description": "Statutory section defining a payment order and fixing when it is issued.", "media_or_form": [ "Statutory text (section page)" ], "serial": false, "identity_strategy": "Identified by article and section number of the uniform act.", "source_refs": [ "SRC-020" ] }, { "id": "payment-order-as-instruction-artifact02", "name": "ISO 20022 pain.001 CustomerCreditTransferInitiation payment information and credit-transfer transaction information", "description": "Initiation message instance carrying payment information blocks and one credit-transfer transaction per payment.", "media_or_form": [ "ISO 20022 XML message instance" ], "serial": true, "identity_strategy": "Identified by message identification and payment information identification, correlated per transaction to the payment.", "source_refs": [ "SRC-016" ] } ], "questions": [ { "id": "payment-order-as-instruction-q01", "text": "When was the payment order issued and received by the receiving PSP, through which initiation channel, and what identifier does the order have distinct from the later FI-to-FI transaction?", "kind": "process", "answer_data": [ "payment_order_id (string)", "issued_at (rfc3339)", "received_at_psp (rfc3339)", "initiation_channel (enum)" ] }, { "id": "payment-order-as-instruction-q02", "text": "Who was the sender of the order, was a PISP involved, and which payment instrument or procedure was used to initiate it?", "kind": "authority", "answer_data": [ "sender_party_ref (party-ref)", "pisp_ref (party-ref)", "payment_instrument_ref (string)", "receiving_bank_ref (party-ref)" ] }, { "id": "payment-order-as-instruction-q03", "text": "What requested execution date or time did the sender give, and how does it relate to scheme cut-off and to the time of receipt that starts legal execution clocks?", "kind": "temporal", "answer_data": [ "requested_execution_date (date)", "requested_execution_time (rfc3339)", "cutoff_applied (string)", "time_of_receipt (rfc3339)" ] } ] } ] } ] }, { "id": "clearing-settlement-and-finality", "name": "Clearing, Settlement and Finality", "description": "How the payment is routed, cleared and settled, in what settlement asset, by what deadline, and at what point it becomes final and discharges the obligation.", "rationale": "International standards for financial market infrastructures set requirements for settlement finality, money settlements and participant default; a central bank RTGS settles in central bank money with immediate finality; and funds-transfer law fixes the moment payment occurs at acceptance by the beneficiary's bank. These are independent, mutually reinforcing normative sources for the settlement layers.", "source_refs": [ "SRC-007", "SRC-010", "SRC-005", "SRC-003", "SRC-012" ], "layers": [ { "id": "routing-and-clearing", "name": "Routing and Clearing", "description": "Selection of the rail and the chain of agents, and the clearing arrangement that determines what is actually settled.", "source_refs": [ "SRC-010", "SRC-012", "SRC-007", "SRC-011" ], "findings": [ { "id": "rail-selection-and-routing-chain", "name": "Rail selection and the routing chain", "description": "A payment is carried either directly through a clearing system or through a correspondent chain, and the settlement method chosen (settlement on the instructed agent's account, on the instructing agent's account, through a cover payment, or through a clearing system) changes who bears which exposure. The clearing and settlement business area is distinct from the initiation area precisely because these are different processes with different participants.", "source_refs": [ "SRC-011", "SRC-012", "SRC-010", "SRC-007" ], "questions": [ { "id": "q-rail-choice", "text": "Which rail or correspondent chain carried this payment, and what alternatives were reachable?", "kind": "decision", "answer_data": [ "Selected rail identifier", "Reachable alternatives", "Selection criteria", "Selecting participant reference" ] }, { "id": "q-settlement-method", "text": "Which settlement method applies between each pair of agents, and where does a cover payment run separately?", "kind": "composition", "answer_data": [ "Settlement method code per hop", "Cover payment reference", "Account relationship used" ] }, { "id": "q-routing-exposure", "text": "Which participant holds credit exposure to which other participant at each stage of the chain?", "kind": "relationship", "answer_data": [ "Exposed participant", "Counterparty participant", "Exposure stage", "Exposure amount" ] }, { "id": "q-cross-rail-translation", "text": "Where the payment crosses between rails or message standards, which fields are lost or truncated?", "kind": "interoperability", "answer_data": [ "Boundary crossed", "Field mapping applied", "Lost or truncated field list", "Mitigation applied" ] } ], "data_elements": [ { "id": "settlement-rail-reference", "name": "Settlement rail reference", "description": "Reference to the clearing or settlement system or correspondent arrangement that carried the payment.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-012" ] }, { "id": "settlement-method-code", "name": "Settlement method code", "description": "Code describing how settlement is effected between two agents on a given hop.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "routing-hop-sequence", "name": "Routing hop sequence", "description": "Ordered sequence of hops the payment actually traversed, with the sending and receiving participant of each.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-004" ] } ], "artifacts": [ { "id": "routing-plan-record", "name": "Routing plan and actual route record", "description": "A record pairing the intended route for a payment with the route it actually took, including each hop, the settlement method applied, any cover payment raised, and deviations from the plan with their causes.", "media_or_form": [ "structured record", "route trace", "operational log" ], "serial": false, "identity_strategy": "Keyed by the payment's authoritative master identifier; the actual route is appended hop by hop as status reports arrive and is never rewritten retrospectively.", "source_refs": [ "SRC-012", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "clearing-cycle-netting-and-settlement-arrangement", "name": "Clearing cycle, netting and settlement asset", "description": "Payments settle either individually and continuously on a gross basis, or as netted positions at defined cycle points. Central bank RTGS settles orders individually and continuously in central bank money with immediate finality and offers liquidity-saving features such as priorities, timed transactions and pooling. International principles require that money settlements minimise and control credit and liquidity risk arising from the choice of settlement asset, so gross versus net and central bank versus commercial bank money are first-order facts about a payment.", "source_refs": [ "SRC-010", "SRC-007", "SRC-008" ], "questions": [ { "id": "q-gross-or-net", "text": "Did this payment settle individually on a gross basis or as part of a netted position, and in which cycle?", "kind": "process", "answer_data": [ "Settlement mode code", "Cycle identifier", "Net position reference", "Cycle close timestamp" ] }, { "id": "q-settlement-asset", "text": "In which settlement asset was the obligation discharged between participants, and who issues that asset?", "kind": "classification", "answer_data": [ "Settlement asset type", "Issuer reference", "Claim characteristics", "Credit risk assessment" ] }, { "id": "q-liquidity-constraint", "text": "Was the payment queued or delayed for liquidity, and which liquidity-saving mechanism resolved it?", "kind": "measurement", "answer_data": [ "Queued flag", "Queue entry timestamp", "Queue release timestamp", "Mechanism applied", "Priority assigned" ] }, { "id": "q-default-handling", "text": "If a participant defaults mid-cycle, what happens to this payment under the system's default rules?", "kind": "exception", "answer_data": [ "Default rule reference", "Unwinding permitted (boolean)", "Payment disposition on default", "Loss allocation basis" ] } ], "data_elements": [ { "id": "settlement-mode-code", "name": "Settlement mode code", "description": "Whether settlement is real-time gross, deferred net or another arrangement.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-007" ] }, { "id": "clearing-cycle-identifier", "name": "Clearing cycle identifier", "description": "Identifier of the clearing cycle or settlement window in which the payment was included.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-010" ] }, { "id": "settlement-asset-type", "name": "Settlement asset type", "description": "Type of asset in which interparticipant settlement occurred, such as central bank money or commercial bank money.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-007" ] }, { "id": "queue-duration", "name": "Queue duration", "description": "Elapsed time the payment spent queued awaiting liquidity before settlement.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "clearing-cycle-settlement-instruction", "name": "Clearing cycle settlement instruction", "description": "The instruction or position statement by which a clearing arrangement effects settlement for a cycle, listing the participants, the net or gross amounts, the settlement asset and the settlement account movements it triggers.", "media_or_form": [ "settlement instruction", "position statement", "batch record" ], "serial": true, "identity_strategy": "Identified by the operator's own cycle and instruction identifier; strictly serial within a rail so that cycles form an ordered, gap-detectable sequence independent of calendar dates.", "source_refs": [ "SRC-007", "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "id": "settlement-and-finality", "name": "Settlement and Finality", "description": "The settlement event itself, its timing obligations and value dating, and the finality point that discharges the obligation.", "source_refs": [ "SRC-003", "SRC-005", "SRC-007", "SRC-010" ], "findings": [ { "id": "settlement-execution-value-date-and-availability", "name": "Settlement execution, value date and availability of funds", "description": "Execution is bounded: the payer's provider must ensure the amount reaches the payee's provider by the end of the business day following receipt, extended by one business day for paper-initiated orders and further for certain intra-area transactions, and the payee's provider must value date and credit on receipt of funds. Value date is a distinct concept from settlement time, defined as the reference time used for interest calculation, so settlement timestamp, value date and availability time are three separate facts that routinely diverge.", "source_refs": [ "SRC-003", "SRC-001", "SRC-002", "SRC-010" ], "questions": [ { "id": "q-execution-deadline-compliance", "text": "What execution deadline applied to this payment, and was it met measured from the deemed time of receipt?", "kind": "requirement", "answer_data": [ "Applicable deadline rule", "Deadline timestamp", "Actual arrival timestamp", "Compliance outcome" ] }, { "id": "q-value-date-versus-settlement", "text": "How do the settlement timestamp, the credit value date and the time funds became available to the payee differ?", "kind": "temporal", "answer_data": [ "Settlement timestamp", "Debit value date", "Credit value date", "Funds availability timestamp" ] }, { "id": "q-float-measurement", "text": "How much value-dating float arose between debit and credit, and to whom did the benefit accrue?", "kind": "measurement", "answer_data": [ "Float duration", "Float value", "Benefiting party reference", "Permitted under rule (boolean)" ] }, { "id": "q-settlement-quality", "text": "How is a settlement record confirmed as authoritative rather than provisional or inferred?", "kind": "quality", "answer_data": [ "Confirmation source", "Confirmation message reference", "Provisional flag", "Reconciliation status" ] } ], "data_elements": [ { "id": "settlement-timestamp", "name": "Settlement timestamp", "description": "Moment at which interparticipant settlement of this payment actually occurred on the rail.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-012" ] }, { "id": "credit-value-date", "name": "Credit value date", "description": "Reference date used for interest calculation on the amount credited to the payee's account.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "funds-availability-timestamp", "name": "Funds availability timestamp", "description": "Moment from which the credited amount became available to the payee for use.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-002" ] }, { "id": "execution-deadline-timestamp", "name": "Execution deadline timestamp", "description": "Latest time by which the amount must reach the payee's provider under the applicable execution rule.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "settlement-confirmation-record", "name": "Settlement confirmation record", "description": "The authoritative confirmation from the settlement operator or receiving agent that a payment settled, carrying the settlement timestamp, settled amount, settlement account movements and the operator's own settlement reference.", "media_or_form": [ "confirmation message", "operator record", "signed advice" ], "serial": false, "identity_strategy": "Identified by the settlement operator's own settlement reference as the authoritative master identifier; the payment's end-to-end reference is carried as a correlating key only.", "source_refs": [ "SRC-010", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "settlement-finality-and-obligation-discharge", "name": "Settlement finality and discharge of the underlying obligation", "description": "Finality is a legal state produced by system rules, not an operational status. Funds-transfer law fixes payment by the originator to the beneficiary at the moment the beneficiary's bank accepts a payment order for the beneficiary, and treats the underlying obligation as discharged to the same extent as a direct money payment, subject to four exceptions covering prohibited payment methods, timely refusal, non-withdrawal and avoidable loss. International principles require systems to define clear and certain final settlement, and a central bank RTGS asserts immediate finality; these two layers of rule must both be recorded because they can fix different moments.", "source_refs": [ "SRC-005", "SRC-007", "SRC-010", "SRC-004" ], "questions": [ { "id": "q-finality-moment", "text": "At what moment did this payment become final, and which system rule or legal rule fixes that moment?", "kind": "state", "answer_data": [ "Finality timestamp", "Fixing rule reference", "Rule layer (system rules, statute, case law)", "Asserting participant reference" ] }, { "id": "q-finality-rule-divergence", "text": "Where the operational finality point and the legal moment of payment differ, which governs for which purpose?", "kind": "authority", "answer_data": [ "Operational finality timestamp", "Legal payment moment", "Divergence reason", "Governing rule per purpose" ] }, { "id": "q-discharge-exceptions", "text": "Do any of the recognised exceptions prevent the underlying obligation from being discharged by this payment?", "kind": "exception", "answer_data": [ "Exception invoked", "Exception basis", "Beneficiary refusal record", "Subrogation outcome" ] }, { "id": "q-post-finality-reversal", "text": "After finality, on what basis could funds still be recovered, and is that a reversal or a new payment?", "kind": "event", "answer_data": [ "Recovery basis", "Mechanism used", "New payment reference", "Original payment left intact (boolean)" ] } ], "data_elements": [ { "id": "finality-state", "name": "Finality state", "description": "Whether the payment is provisional, conditionally final or unconditionally final under the governing system rules.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-010" ] }, { "id": "finality-timestamp", "name": "Finality timestamp", "description": "Moment at which the payment became final under the governing rule.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-005" ] }, { "id": "obligation-discharge-state", "name": "Obligation discharge state", "description": "Whether the underlying monetary obligation is treated as discharged, partly discharged or not discharged.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "governing-system-rules-reference", "name": "Governing system rules reference", "description": "Reference to the system rules, statute or scheme rulebook that determines finality for this payment.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-005" ] } ], "artifacts": [ { "id": "finality-attestation", "name": "Finality attestation", "description": "A record asserting that a payment reached finality, naming the rule under which finality arose, the attesting participant, the finality timestamp and the consequences asserted for the underlying obligation.", "media_or_form": [ "attestation record", "legal notice", "structured assertion" ], "serial": false, "identity_strategy": "Keyed by the settlement operator's settlement reference where the operator attests, otherwise by the attesting participant identifier plus the payment master identifier; an attestation is never identified by its date.", "source_refs": [ "SRC-007", "SRC-005", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "exchange-of-value-linkage", "name": "Exchange-of-value linkage", "description": "PFMI Principle 12 requires that if an FMI settles two linked obligations, it eliminate principal risk by conditioning final settlement of one upon final settlement of the other. A PvP system ensures that the final payment of one currency occurs if and only if the final payment of the other occurs. DvP model 1 settles securities and funds gross, obligation by obligation, with final transfer of securities if and only if final transfer of funds occurs. This model records the payment leg and the linkage condition; the securities or FX trade objects remain in sibling models.", "source_refs": [ "SRC-018", "SRC-017" ], "inline_only_rationale": null, "data_elements": [ { "id": "exchange-of-value-linkage-data01", "name": "linked_obligation_type", "description": "Type of obligation whose settlement this leg is conditioned on.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-017" ] }, { "id": "exchange-of-value-linkage-data02", "name": "linked_payment_ref", "description": "Reference to the linked payment leg.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-017" ] }, { "id": "exchange-of-value-linkage-data03", "name": "linked_securities_instruction_ref", "description": "Reference to the linked securities delivery instruction held in a sibling model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-017" ] }, { "id": "exchange-of-value-linkage-data04", "name": "pvp_or_dvp_model", "description": "Which exchange-of-value model applies to the linkage.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-017" ] }, { "id": "exchange-of-value-linkage-data05", "name": "conditionality_rule", "description": "Rule making final settlement of this leg conditional on the other leg.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-017" ] }, { "id": "exchange-of-value-linkage-data06", "name": "principal_risk_eliminated", "description": "Whether the linkage eliminates principal risk.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-017" ] } ], "artifacts": [ { "id": "exchange-of-value-linkage-artifact01", "name": "PFMI Principle 12 exchange-of-value settlement systems and CPMI glossary DvP/PvP finality language", "description": "Principle and glossary language conditioning final settlement of one obligation on final settlement of the linked obligation.", "media_or_form": [ "Principle text (BIS principle index)", "Published glossary (PDF)" ], "serial": false, "identity_strategy": "Identified by PFMI principle number and glossary term.", "source_refs": [ "SRC-018", "SRC-017" ] } ], "questions": [ { "id": "exchange-of-value-linkage-q01", "text": "Is this payment's finality conditioned on another payment, a securities delivery or another obligation, and which record is the linked leg?", "kind": "composition", "answer_data": [ "linked_obligation_type (enum)", "linked_payment_ref (payment-ref)", "linked_securities_instruction_ref (string)", "pvp_or_dvp_model (enum)" ] }, { "id": "exchange-of-value-linkage-q02", "text": "What rule makes settlement of this leg occur only if the other leg settles, and is principal risk thereby eliminated?", "kind": "constraint", "answer_data": [ "conditionality_rule (string)", "principal_risk_eliminated (boolean)" ] }, { "id": "exchange-of-value-linkage-q03", "text": "If the linked leg fails, is this payment rejected, held, unwound or settled independently?", "kind": "lifecycle", "answer_data": [ "linked_failure_action (enum)", "unwind_indicator (boolean)" ] } ] }, { "id": "instant-execution-clocks-and-settlement-lag", "name": "Execution clocks, value date and instant SLA", "description": "CPMI settlement lag is the time between acceptance of the transfer order by the system and final settlement. PSD2 execution clocks run from time of receipt. For EU instant credit transfers, time of receipt is the moment the payer's PSP receives the order regardless of hour or calendar day; the payer's PSP must immediately verify conditions and funds and send the transaction; the payee's PSP must make funds available and confirm completion within 10 seconds of that time of receipt. EPC SCT Inst scheme rules add tighter originator-PSP response expectations. Value date is a business date, not an identifier. Event time and ingestion time must be stored separately when they differ.", "source_refs": [ "SRC-024", "SRC-019", "SRC-017", "SRC-021" ], "inline_only_rationale": null, "data_elements": [ { "id": "instant-execution-clocks-and-settlement-lag-data01", "name": "time_of_receipt", "description": "Instant the payer's PSP received the order, which starts execution clocks.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-019", "SRC-017", "SRC-021" ] }, { "id": "instant-execution-clocks-and-settlement-lag-data02", "name": "execution_date", "description": "Business date of execution.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-019", "SRC-017", "SRC-021" ] }, { "id": "instant-execution-clocks-and-settlement-lag-data03", "name": "value_date", "description": "Business value date applied to the transfer.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-019", "SRC-017", "SRC-021" ] }, { "id": "instant-execution-clocks-and-settlement-lag-data04", "name": "settled_at", "description": "Instant of settlement.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-019", "SRC-017", "SRC-021" ] }, { "id": "instant-execution-clocks-and-settlement-lag-data05", "name": "funds_available_at", "description": "Instant funds were made available to the payee.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-019", "SRC-017", "SRC-021" ] }, { "id": "instant-execution-clocks-and-settlement-lag-data06", "name": "confirmation_at", "description": "Instant completion was confirmed to the originator.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-019", "SRC-017", "SRC-021" ] }, { "id": "instant-execution-clocks-and-settlement-lag-data07", "name": "sla_seconds", "description": "Service-level window in seconds applicable to the transfer.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-019", "SRC-017", "SRC-021" ] }, { "id": "instant-execution-clocks-and-settlement-lag-data08", "name": "sla_met", "description": "Whether the applicable window was met.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-019", "SRC-017", "SRC-021" ] }, { "id": "instant-execution-clocks-and-settlement-lag-data09", "name": "observed_at", "description": "Instant this Dimension observed or ingested the fact.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-019", "SRC-017", "SRC-021" ] }, { "id": "instant-execution-clocks-and-settlement-lag-data10", "name": "settlement_lag_seconds", "description": "Seconds between acceptance by the system and final settlement.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-019", "SRC-017", "SRC-021" ] } ], "artifacts": [ { "id": "instant-execution-clocks-and-settlement-lag-artifact01", "name": "Regulation 260/2012 as amended — instant credit-transfer time of receipt, 10-second availability and confirmation", "description": "Legislative clauses fixing time of receipt and the ten-second availability and confirmation duties for instant credit transfers.", "media_or_form": [ "Consolidated legislative text (EUR-Lex HTML)" ], "serial": false, "identity_strategy": "Identified by CELEX number, consolidation date and article reference.", "source_refs": [ "SRC-024" ] } ], "questions": [ { "id": "instant-execution-clocks-and-settlement-lag-q01", "text": "What are the time of receipt, execution date, value date, funds-available time and final-settlement time, each with RFC 3339 seconds and offset where they are instants, and what is the observation or ingestion time of this record?", "kind": "temporal", "answer_data": [ "time_of_receipt (rfc3339)", "execution_date (date)", "value_date (date)", "funds_available_at (rfc3339)", "settled_at (rfc3339)", "observed_at (rfc3339)" ] }, { "id": "instant-execution-clocks-and-settlement-lag-q02", "text": "If the payment is instant, what SLA in seconds applied, was it met, and how many seconds elapsed from time of receipt to payee availability and to originator confirmation?", "kind": "measurement", "answer_data": [ "sla_seconds (integer)", "sla_met (boolean)", "availability_lag_seconds (integer)", "confirmation_lag_seconds (integer)" ] }, { "id": "instant-execution-clocks-and-settlement-lag-q03", "text": "What settlement lag elapsed from system acceptance to final settlement, and did the payment miss value date?", "kind": "process", "answer_data": [ "accepted_for_settlement_at (rfc3339)", "settlement_lag_seconds (integer)", "missed_value_date (boolean)" ] } ] } ] } ] }, { "id": "lifecycle-status-and-exceptions", "name": "Lifecycle, Status and Exception Handling", "description": "The observable state of a payment over time, and every path by which value comes back: refusal, return, reversal, recall, refund, chargeback and unauthorised-transaction claims.", "rationale": "Operators publish dedicated status, return, return-request and investigation messages, and consumer protection rules impose hard investigation deadlines and provisional credit duties. Exceptions are therefore a normatively specified part of the aggregate rather than an error path, and status must be modelled as reported-by-participant rather than as a single global truth.", "source_refs": [ "SRC-012", "SRC-013", "SRC-002", "SRC-011" ], "layers": [ { "id": "status-and-lifecycle", "name": "Status and Lifecycle History", "description": "Status codes and reason codes as reported by each participant, and the ordered event history behind them.", "source_refs": [ "SRC-012", "SRC-011", "SRC-002" ], "findings": [ { "id": "status-model-and-reason-codes", "name": "Status model, reason codes and reporting participant", "description": "Status is reported through dedicated status messages and is always relative to the reporting participant and the leg it observed; a payment can be settled on one leg and pending on another. Refusal must carry reasons where lawful. Because reason code sets are scheme-governed and only partially harmonised, a status must be stored with its code set identity or it cannot be reliably interpreted later.", "source_refs": [ "SRC-012", "SRC-011", "SRC-002" ], "questions": [ { "id": "q-status-scope", "text": "Which participant reported this status, about which leg, and as at what moment?", "kind": "state", "answer_data": [ "Reporting participant reference", "Leg identifier", "Status code", "Status as-at timestamp" ] }, { "id": "q-status-code-set", "text": "Which code set does this status reason belong to, and what is its meaning in that set's version?", "kind": "classification", "answer_data": [ "Code set identifier", "Code set version", "Reason code", "Decoded meaning" ] }, { "id": "q-status-conflict", "text": "When two participants report conflicting statuses for the same payment, which is treated as authoritative?", "kind": "quality", "answer_data": [ "Conflicting status pair", "Precedence rule applied", "Resolved status", "Resolution timestamp" ] }, { "id": "q-status-mapping-loss", "text": "What information is lost when a scheme reason code is mapped to an internal or customer-facing status?", "kind": "interoperability", "answer_data": [ "Source code", "Target status", "Mapping table reference", "Lost distinctions" ] } ], "data_elements": [ { "id": "payment-status-code", "name": "Payment status code", "description": "Status of the payment or of one leg of it as reported by a named participant.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-011" ] }, { "id": "status-reason-code", "name": "Status reason code", "description": "Coded reason accompanying a status, interpreted against a named and versioned code set.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-002" ] }, { "id": "status-reporting-participant", "name": "Status reporting participant", "description": "Reference to the participant that reported a given status.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "payment-status-report", "name": "Payment status report", "description": "A report from one participant on the status of one or more payments, carrying the status code, reason code, code set version, the references it responds to and the moment the status was determined.", "media_or_form": [ "status message", "structured report", "callback payload" ], "serial": false, "identity_strategy": "Identified by the reporting participant's own status message identifier; correlated to the payment through the references it echoes rather than by minting a payment identifier.", "source_refs": [ "SRC-012", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "lifecycle-event-history", "name": "Lifecycle event history and state transitions", "description": "The payment aggregate is reconstructed from an ordered event history: instructed, received, authorised, accepted or refused, cleared, settled, made final, and any return, recall or dispute. Each event has an event time on the rail and an observation time at which the adopting Dimension learned of it, and these frequently differ by hours; conflating them corrupts both deadline computation and audit.", "source_refs": [ "SRC-012", "SRC-002", "SRC-007" ], "questions": [ { "id": "q-event-ordering", "text": "What is the ordered sequence of lifecycle events for this payment, and how is ordering established across participants?", "kind": "lifecycle", "answer_data": [ "Event type sequence", "Ordering basis", "Sequence number", "Cross-participant reconciliation note" ] }, { "id": "q-event-versus-observation-time", "text": "For each event, when did it occur on the rail and when was it observed or ingested here?", "kind": "temporal", "answer_data": [ "Event timestamp", "Observation timestamp", "Latency", "Time source" ] }, { "id": "q-transition-legality", "text": "Which state transitions are permitted from the current state, and which observed transition was invalid?", "kind": "event", "answer_data": [ "Current state", "Permitted next states", "Observed transition", "Validity outcome" ] }, { "id": "q-event-source-trust", "text": "What is the source and trust level of each recorded event, and was any event inferred rather than reported?", "kind": "provenance", "answer_data": [ "Event source participant", "Source channel", "Inferred flag", "Inference basis" ] } ], "data_elements": [ { "id": "lifecycle-event-type", "name": "Lifecycle event type", "description": "Type of lifecycle event recorded against the payment.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-002" ] }, { "id": "event-occurrence-timestamp", "name": "Event occurrence timestamp", "description": "Moment the event actually occurred at its source.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-010" ] }, { "id": "event-observation-timestamp", "name": "Event observation timestamp", "description": "Moment the adopting Dimension observed or ingested the event, held separately from occurrence time.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "event-source-participant", "name": "Event source participant", "description": "Reference to the participant or system that reported the event.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "payment-event-log", "name": "Payment lifecycle event log", "description": "An append-only, ordered log of every lifecycle event recorded for one payment, each entry carrying event type, occurrence time, observation time, source participant, prior and resulting state, and the message or record that evidenced it.", "media_or_form": [ "append-only log", "event stream", "structured record set" ], "serial": true, "identity_strategy": "Keyed by the payment's authoritative master identifier with a strictly increasing local sequence number per entry; sequence numbers are gap-detectable and never reused, and entries are never rewritten.", "source_refs": [ "SRC-012", "SRC-002" ] } ], "inline_only_rationale": null } ] }, { "id": "returns-recalls-and-disputes", "name": "Returns, Recalls and Disputes", "description": "The reverse-direction paths by which value or liability moves back, and the statutory deadlines that constrain them.", "source_refs": [ "SRC-012", "SRC-013", "SRC-002" ], "findings": [ { "id": "returns-reversals-and-recalls", "name": "Returns, reversals and recall requests", "description": "Distinct mechanisms are frequently conflated. A return is a new payment in the opposite direction raised by the receiving side; a return request asks the receiving side to return a settled payment and may be refused; a response message conveys that refusal or agreement; and a reversal in some schemes undoes an entry rather than creating a new one. Each has its own reference, reason code set and timing window, and the original payment usually remains valid and final.", "source_refs": [ "SRC-012", "SRC-002", "SRC-004" ], "questions": [ { "id": "q-return-mechanism", "text": "Which mechanism was used to move value back, and did it create a new payment or unwind the original?", "kind": "process", "answer_data": [ "Mechanism code", "New payment reference", "Original payment left final (boolean)", "Scheme rule reference" ] }, { "id": "q-return-reason-and-window", "text": "What reason was cited for the return or recall, and was it raised within the scheme's permitted window?", "kind": "temporal", "answer_data": [ "Reason code", "Window duration", "Raised timestamp", "Within window (boolean)" ] }, { "id": "q-recall-refusal", "text": "Where a recall request was refused, on what ground, and what remedy remains to the requester?", "kind": "exception", "answer_data": [ "Refusal ground code", "Refusing participant", "Remaining remedies", "Escalation path" ] }, { "id": "q-return-linkage", "text": "How is a returned payment linked back to the original so that neither is double-counted?", "kind": "relationship", "answer_data": [ "Original payment reference", "Return payment reference", "Linkage type", "Net economic effect" ] } ], "data_elements": [ { "id": "return-payment-reference", "name": "Return payment reference", "description": "Reference of the payment raised to return value to the original payer.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "return-reason-code", "name": "Return reason code", "description": "Coded reason for a return or return request, interpreted against a named scheme code set.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-002" ] }, { "id": "returned-amount", "name": "Returned amount", "description": "Amount actually returned, which may be less than the original amount after charges.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "return-or-recall-case-record", "name": "Return or recall case record", "description": "A case record linking an original payment to a return request, the response received, any resulting return payment, the reason codes at each step and the amounts actually recovered.", "media_or_form": [ "case record", "message exchange log", "structured record set" ], "serial": false, "identity_strategy": "Identified by the scheme's own case reference where assigned; otherwise by a Dimension-assigned ULID, always linked to the original payment's authoritative master identifier.", "source_refs": [ "SRC-012", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "disputes-unauthorised-claims-and-error-resolution", "name": "Disputes, unauthorised claims and error resolution", "description": "Consumer rules define an error broadly, require notice within sixty days of the statement first reflecting it, oblige the institution to investigate within ten business days or extend to forty-five days with provisional credit, and to report results within three business days of completing the investigation. Separate rules cap payer liability for lost or stolen instruments, remove liability after notification or where strong authentication was not applied, and set a thirteen-month outer limit for unauthorised-transaction claims. These are hard deadlines with defined start events, so the model must record which event started each clock.", "source_refs": [ "SRC-013", "SRC-002", "SRC-014" ], "questions": [ { "id": "q-dispute-clock-start", "text": "Which event started the dispute or claim clock, and when does each applicable deadline expire?", "kind": "temporal", "answer_data": [ "Clock start event", "Clock start timestamp", "Deadline list with expiry timestamps", "Governing rule reference" ] }, { "id": "q-provisional-credit", "text": "Was provisional credit required, in what amount, and was it granted within the prescribed period?", "kind": "requirement", "answer_data": [ "Provisional credit required (boolean)", "Credit amount", "Credit granted timestamp", "Compliance outcome" ] }, { "id": "q-liability-allocation", "text": "Who bears the loss for this disputed payment, and which factor determined the allocation?", "kind": "ownership", "answer_data": [ "Liability holder reference", "Liability amount", "Determining factor", "Liability cap applied" ] }, { "id": "q-dispute-evidence", "text": "What evidence was gathered and disclosed to the claimant, and in what readable form?", "kind": "evidence", "answer_data": [ "Evidence item list", "Disclosure timestamp", "Format converted to readable form (boolean)", "Withheld items and basis" ] } ], "data_elements": [ { "id": "dispute-case-reference", "name": "Dispute case reference", "description": "Reference of the dispute, chargeback or unauthorised-transaction case raised against the payment.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-002" ] }, { "id": "investigation-deadline-timestamp", "name": "Investigation deadline timestamp", "description": "Latest moment by which the investigation must be completed or extended under the governing rule.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "provisional-credit-amount", "name": "Provisional credit amount", "description": "Amount provisionally credited to the claimant pending the outcome of the investigation.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "liability-allocation-outcome", "name": "Liability allocation outcome", "description": "Determination of which party bears the loss and under which liability rule or cap.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-013" ] } ], "artifacts": [ { "id": "dispute-case-file", "name": "Dispute case file", "description": "The complete file for one dispute: the claim as received, the clock start event, every deadline and whether it was met, evidence gathered from each participant, provisional credit movements, the determination and the written explanation supplied to the claimant.", "media_or_form": [ "case file", "evidence pack", "structured record set with attachments" ], "serial": false, "identity_strategy": "Identified by the case reference assigned by the investigating institution or scheme as authoritative master identifier; linked to but never identified by the disputed payment's reference, since one case may span several payments.", "source_refs": [ "SRC-013", "SRC-002" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "obligation-evidence-and-governance", "name": "Obligation Linkage, Evidence and Governance", "description": "What the payment is for, what it discharges, what evidence it produces, how it reconciles into accounting, and how the resulting records are governed.", "rationale": "Legal discharge of the underlying obligation is the purpose of most payments, and it is separately regulated from settlement. Remittance is a distinct standardised business area, cash reporting messages carry the evidence, and security and consumer standards constrain who may see payment records and for how long they may be kept.", "source_refs": [ "SRC-005", "SRC-011", "SRC-012", "SRC-014", "SRC-015" ], "layers": [ { "id": "obligation-linkage-and-remittance", "name": "Obligation Linkage and Remittance", "description": "What obligation the payment discharges, in what amount, and the remittance and purpose data that make that linkage machine-resolvable.", "source_refs": [ "SRC-005", "SRC-011", "SRC-012" ], "findings": [ { "id": "obligation-discharge-and-allocation", "name": "Obligation linkage and allocation of the paid amount", "description": "A payment discharges the underlying obligation to the same extent as a direct money payment, but discharge is conditional and can be defeated. Practically, one payment may discharge several obligations partly, and several payments may discharge one obligation, so allocation is an explicit many-to-many structure with residuals; it cannot be inferred from amount matching alone without producing silent misallocation.", "source_refs": [ "SRC-005", "SRC-001", "SRC-004" ], "questions": [ { "id": "q-discharged-obligations", "text": "Which obligations does this payment discharge, in what allocated amounts, and who decided the allocation?", "kind": "relationship", "answer_data": [ "Obligation reference list", "Allocated amount per obligation", "Allocating party reference", "Allocation timestamp" ] }, { "id": "q-allocation-residual", "text": "What residual remains unallocated or unpaid after this payment, and how is it carried forward?", "kind": "measurement", "answer_data": [ "Unallocated payment amount", "Residual obligation balance", "Carry-forward treatment" ] }, { "id": "q-discharge-conditionality", "text": "Under what conditions could this discharge be undone, and what would then revive the obligation?", "kind": "constraint", "answer_data": [ "Reversal condition list", "Revival mechanism", "Notification duty", "Governing rule reference" ] } ], "data_elements": [ { "id": "discharged-obligation-reference", "name": "Discharged obligation reference", "description": "Reference to an obligation, invoice or claim that this payment discharges in whole or in part.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-001" ] }, { "id": "allocated-amount", "name": "Allocated amount", "description": "Portion of the payment applied against one specific obligation.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "residual-obligation-balance", "name": "Residual obligation balance", "description": "Amount of the obligation remaining outstanding after this payment is applied.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "payment-allocation-advice", "name": "Payment allocation advice", "description": "A statement issued by or on behalf of the payer setting out which obligations the payment is applied against, in what amounts, with the residual position after application, used by the payee to clear its receivables.", "media_or_form": [ "remittance advice", "allocation statement", "structured record set" ], "serial": false, "identity_strategy": "Identified by the issuing party's own advice reference as authoritative master identifier; linked to the payment master identifier and to each obligation reference it allocates against.", "source_refs": [ "SRC-005", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "remittance-information-and-purpose", "name": "Remittance information and payment purpose", "description": "Remittance is a distinct standardised business area, and purpose and category purpose codes classify why a payment is made independently of what it discharges. Remittance may travel inside the payment or separately as a standalone advice with a location reference; the choice materially affects reconciliation success and also determines how much commercially sensitive detail is exposed to intermediary agents.", "source_refs": [ "SRC-011", "SRC-012", "SRC-001" ], "questions": [ { "id": "q-purpose-classification", "text": "What purpose and category purpose are declared for this payment, and who assigned them?", "kind": "classification", "answer_data": [ "Purpose code", "Category purpose code", "Code set version", "Assigning party reference" ] }, { "id": "q-remittance-carriage", "text": "Does remittance information travel inside the payment or as a separate advice, and how are the two bound?", "kind": "composition", "answer_data": [ "Carriage mode", "Remittance location reference", "Binding identifier", "Delivery confirmation" ] }, { "id": "q-remittance-truncation", "text": "Where remittance data exceeds what a rail can carry, what is truncated and how is the loss signalled?", "kind": "interoperability", "answer_data": [ "Rail capacity limit", "Truncated content", "Truncation signal", "Fallback channel used" ] }, { "id": "q-remittance-exposure", "text": "Which intermediaries can read the remittance content, and does it disclose commercially sensitive detail?", "kind": "privacy", "answer_data": [ "Reading participant list", "Sensitivity classification", "Redaction option available (boolean)", "Contractual confidentiality basis" ] } ], "data_elements": [ { "id": "purpose-code", "name": "Purpose code", "description": "Coded reason for the payment as declared by the initiating party, from a named code set.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-011" ] }, { "id": "structured-remittance-information", "name": "Structured remittance information", "description": "Machine-readable remittance content such as referenced document identifiers, amounts and adjustment reasons.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] }, { "id": "unstructured-remittance-information", "name": "Unstructured remittance information", "description": "Free-text remittance narrative carried with the payment.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "standalone-remittance-advice", "name": "Standalone remittance advice", "description": "A remittance advice transmitted separately from the payment, carrying the referenced documents, amounts and adjustments, and bound to the payment through a shared reference so that the payee can reconcile without relying on rail-carried narrative.", "media_or_form": [ "remittance advice message", "document set", "structured payload" ], "serial": false, "identity_strategy": "Identified by the sending party's own remittance advice identifier; the binding to the payment is by shared end-to-end reference and is validated on receipt rather than assumed.", "source_refs": [ "SRC-011", "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "evidence-and-reconciliation", "name": "Evidence and Reconciliation", "description": "The confirmations, advices and statements a payment produces, and the reconciliation that turns them into accounting facts.", "source_refs": [ "SRC-012", "SRC-011", "SRC-010" ], "findings": [ { "id": "confirmations-advices-and-statements", "name": "Confirmations, advices and account statements", "description": "Cash management messages carry the evidence layer: intraday reports, end-of-day statements and debit or credit advices, each with its own entry references. These are the records a payee actually reconciles against and a court would inspect, and they are produced by the account servicer rather than by the payer, so their provenance and completeness differ from the instruction record.", "source_refs": [ "SRC-011", "SRC-012", "SRC-010" ], "questions": [ { "id": "q-evidence-issuer", "text": "Which party issued each confirmation, advice or statement, and what does that party actually attest to?", "kind": "provenance", "answer_data": [ "Issuing party reference", "Document type", "Scope of attestation", "Issue timestamp" ] }, { "id": "q-entry-reference-binding", "text": "How does a statement entry bind back to the payment, and what happens when the binding reference is absent?", "kind": "evidence", "answer_data": [ "Entry reference", "Binding key used", "Unbound entry handling", "Manual match indicator" ] }, { "id": "q-statement-completeness", "text": "Is the statement series complete and gap-free, and how are missing or duplicated statements detected?", "kind": "quality", "answer_data": [ "Sequence numbers received", "Gap list", "Duplicate list", "Detection method" ] }, { "id": "q-evidence-disclosure", "text": "Which parties may obtain a copy of the payment evidence, and on what lawful basis?", "kind": "access", "answer_data": [ "Requesting party role", "Disclosure basis", "Redactions applied", "Disclosure record reference" ] } ], "data_elements": [ { "id": "statement-reference", "name": "Statement reference", "description": "Reference of an account statement or report in which the payment appears as an entry.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] }, { "id": "entry-reference", "name": "Entry reference", "description": "Account servicer's reference for the specific entry representing this payment.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "advice-issuer-reference", "name": "Advice issuer reference", "description": "Reference to the account servicer or operator that issued a confirmation or advice.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-010" ] } ], "artifacts": [ { "id": "payment-confirmation-and-statement", "name": "Payment confirmation and account statement", "description": "The account servicer's confirmation, advice or statement evidencing the debit or credit of a payment, carrying entry references, booking and value dates, running balances and the statement sequence that allows completeness checking.", "media_or_form": [ "statement message", "advice document", "structured report" ], "serial": true, "identity_strategy": "Identified by the account servicer's own statement or advice identifier as authoritative master identifier, with a strictly serial statement sequence number per account enabling gap detection independent of dates.", "source_refs": [ "SRC-011", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "reconciliation-and-accounting-handoff", "name": "Reconciliation and handoff to accounting", "description": "Reconciliation matches an instructed payment to the settlement confirmation and to the statement entry, and only then is a defensible posting produced. The handoff to the accounting model is a composition boundary: this model asserts the economic facts and their evidence, while posting rules, account selection and period assignment belong to the financial transaction model.", "source_refs": [ "SRC-012", "SRC-011", "SRC-007" ], "questions": [ { "id": "q-match-state", "text": "What is the current three-way match state between instruction, settlement confirmation and statement entry?", "kind": "validation", "answer_data": [ "Match state code", "Matched references", "Unmatched side", "Match timestamp" ] }, { "id": "q-posting-handoff", "text": "Which facts does this model hand to the accounting model, and which decisions does it deliberately not make?", "kind": "process", "answer_data": [ "Handed fact set", "Excluded decision list", "Handoff interface reference", "Posting reference returned" ] }, { "id": "q-break-ageing", "text": "How long has each reconciliation break been open, and what is the escalation threshold?", "kind": "measurement", "answer_data": [ "Break reference", "Break age", "Escalation threshold", "Owning role" ] }, { "id": "q-restatement-effect", "text": "If a payment fact is later corrected, how is the previously produced posting handled?", "kind": "quality", "answer_data": [ "Correction type", "Original posting reference", "Correction mechanism", "Period impact" ] } ], "data_elements": [ { "id": "reconciliation-match-state", "name": "Reconciliation match state", "description": "State of the match between the instruction, the settlement confirmation and the statement entry.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-011" ] }, { "id": "ledger-posting-reference", "name": "Ledger posting reference", "description": "Reference returned by the accounting model for the posting generated from this payment.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "reconciliation-break-reference", "name": "Reconciliation break reference", "description": "Reference to an unresolved reconciliation break involving this payment.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "reconciliation-result-set", "name": "Reconciliation result set", "description": "The output of one reconciliation run over a population of payments: matched sets with their binding keys, unmatched items on each side, break classifications, ages and owners, and the postings emitted as a result.", "media_or_form": [ "result set", "exception report", "structured record set" ], "serial": true, "identity_strategy": "Identified by a serial run identifier assigned by the reconciling system, never by the run date; individual results are keyed by the payment master identifier within the run.", "source_refs": [ "SRC-012", "SRC-011" ] } ], "inline_only_rationale": null } ] }, { "id": "compliance-access-and-retention", "name": "Compliance, Access and Retention", "description": "Regulatory obligations attaching to the payment record, and the access, retention and deletion regime that governs it.", "source_refs": [ "SRC-014", "SRC-015", "SRC-013", "SRC-002" ], "findings": [ { "id": "regulatory-regime-and-transferred-compliance-data", "name": "Applicable regulatory regime and transferred compliance data", "description": "Which regime applies is not a property of the amount but of the parties, the instrument, the currency or token, and the jurisdictions touched. Token-denominated transfers referencing an official currency sit under a distinct authorisation regime with issuer obligations and a phased application timeline, so a payment aggregate must record its applicable regime explicitly rather than assuming one default. Compliance data that must travel with the payment is a separate concern from the data the payment needs to settle.", "source_refs": [ "SRC-015", "SRC-001", "SRC-014", "SRC-002" ], "questions": [ { "id": "q-applicable-regime", "text": "Which regulatory regimes apply to this payment, and which jurisdictions triggered each of them?", "kind": "authority", "answer_data": [ "Regime reference list", "Triggering jurisdiction per regime", "Determination basis", "Determination timestamp" ] }, { "id": "q-jurisdiction-touchpoints", "text": "Which jurisdictions did the payment touch through its parties, agents and settlement location?", "kind": "spatial", "answer_data": [ "Party jurisdictions", "Agent jurisdictions", "Settlement location", "Data residency implications" ] }, { "id": "q-transferred-compliance-data", "text": "Which originator and beneficiary information had to accompany the transfer, and was it complete on arrival?", "kind": "requirement", "answer_data": [ "Required data set", "Transmitted data set", "Missing elements", "Receiving institution action" ] }, { "id": "q-regime-change-effect", "text": "When a regime's application date falls between instruction and settlement, which rules govern this payment?", "kind": "temporal", "answer_data": [ "Regime application date", "Instruction timestamp", "Settlement timestamp", "Governing rule determination" ] } ], "data_elements": [ { "id": "applicable-regime-reference", "name": "Applicable regime reference", "description": "Reference to a regulatory regime determined to apply to this payment, with its triggering basis.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-001" ] }, { "id": "originator-information-set", "name": "Originator information set", "description": "The set of originator details required to accompany the transfer under the applicable regime.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-015" ] }, { "id": "beneficiary-information-set", "name": "Beneficiary information set", "description": "The set of beneficiary details required to accompany the transfer under the applicable regime.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-015" ] } ], "artifacts": [ { "id": "regulatory-determination-record", "name": "Regulatory determination record", "description": "A dated record of which regimes were determined to apply to a payment, the facts relied on, the rule versions in force at determination time and the resulting data and reporting obligations, so that a later challenge can be answered on the basis known at the time.", "media_or_form": [ "determination record", "compliance memorandum", "structured assertion" ], "serial": false, "identity_strategy": "Keyed by the payment's authoritative master identifier plus determination sequence; determinations are appended, never overwritten, so superseded determinations remain inspectable.", "source_refs": [ "SRC-015", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "access-control-retention-and-deletion", "name": "Access control, retention and deletion of payment records", "description": "Payment records mix commercially confidential data, personal data and, for card payments, data whose storage is externally restricted: the applicable security standard scopes every entity that stores, processes or transmits cardholder data or sensitive authentication data. Retention is pulled in opposite directions by evidential duties (claims can be raised many months after the debit and investigations have defined response duties) and by minimisation duties, so the model must record a per-element retention basis rather than one blanket period.", "source_refs": [ "SRC-014", "SRC-002", "SRC-013" ], "questions": [ { "id": "q-access-default", "text": "Who may read a payment record by default, and which additional roles require an explicit grant?", "kind": "access", "answer_data": [ "Default reader roles", "Grant-required roles", "Granting steward", "Grant scope and expiry" ] }, { "id": "q-element-level-retention", "text": "What retention basis and period applies to each class of element, and which elements must be purged earliest?", "kind": "retention", "answer_data": [ "Element class", "Retention basis", "Retention period", "Earliest purge trigger" ] }, { "id": "q-deletion-versus-immutability", "text": "How is a deletion obligation satisfied against an append-only settlement and event record that must remain intact?", "kind": "privacy", "answer_data": [ "Deletion technique", "Elements redacted", "Elements retained", "Integrity preservation method" ] }, { "id": "q-restricted-element-storage", "text": "Which elements are prohibited from storage after authorisation, and how is that prohibition enforced and tested?", "kind": "security", "answer_data": [ "Prohibited element list", "Enforcement control", "Testing method", "Last verification timestamp" ] } ], "data_elements": [ { "id": "access-scope-descriptor", "name": "Access scope descriptor", "description": "Descriptor of who may access which part of a payment record and under what conditions.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-002" ] }, { "id": "retention-basis-code", "name": "Retention basis code", "description": "The legal or contractual basis for retaining a class of payment data, from which the retention period follows.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-002" ] }, { "id": "purge-or-redaction-timestamp", "name": "Purge or redaction timestamp", "description": "Moment at which an element was purged or redacted, retained as a fact even after the element itself is gone.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "legal-hold-flag", "name": "Legal hold flag", "description": "Indicator that scheduled deletion is suspended because of litigation, investigation or regulatory demand.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "retention-and-access-policy-binding", "name": "Retention and access policy binding", "description": "The binding that attaches a named retention schedule and access policy to each element class of a payment record, together with the executed purge and redaction log showing what was removed, when, by which process and under which basis.", "media_or_form": [ "policy binding", "retention schedule", "purge log" ], "serial": true, "identity_strategy": "Identified by policy identifier plus version for the binding, and keyed by payment master identifier plus element class for each executed purge entry; purge entries are append-only and survive the data they removed.", "source_refs": [ "SRC-014", "SRC-013", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "travel-rule-payload-and-screening", "name": "Travel-rule payload and screening", "description": "FATF Recommendation 16 requires countries to ensure that financial institutions include required and accurate originator information and required beneficiary information on wire payments or value transfers and related messages. The June 2025 update standardises responsibilities in the payment chain, starting with the institution that receives the customer instruction, and applies enhanced data for peer-to-peer cross-border payments above USD/EUR 1,000 (name, address, date of birth among other fields). The EU Transfer of Funds rules require the payer's PSP to accompany transfers with payer and payee name and account number (or unique transaction identifier where no account), plus specified identity details, and to verify payer information before execution; the payee's PSP must detect missing data and may execute, reject or suspend. Screening against restrictive measures is a pre-execution control; list contents are out of scope. Crypto-asset transfers are covered by the TFR recast; detailed on-chain semantics remain a gap.", "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ], "inline_only_rationale": null, "data_elements": [ { "id": "travel-rule-payload-and-screening-data01", "name": "originator_name", "description": "Originator name that must accompany the transfer.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] }, { "id": "travel-rule-payload-and-screening-data02", "name": "originator_account_id", "description": "Originator account number accompanying the transfer.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] }, { "id": "travel-rule-payload-and-screening-data03", "name": "originator_address", "description": "Structured originator address accompanying the transfer.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] }, { "id": "travel-rule-payload-and-screening-data04", "name": "originator_lei", "description": "Legal entity identifier of the originator.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] }, { "id": "travel-rule-payload-and-screening-data05", "name": "originator_dob", "description": "Originator date of birth where enhanced data applies.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] }, { "id": "travel-rule-payload-and-screening-data06", "name": "beneficiary_name", "description": "Beneficiary name that must accompany the transfer.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] }, { "id": "travel-rule-payload-and-screening-data07", "name": "beneficiary_account_id", "description": "Beneficiary account number accompanying the transfer.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] }, { "id": "travel-rule-payload-and-screening-data08", "name": "beneficiary_lei", "description": "Legal entity identifier of the beneficiary.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] }, { "id": "travel-rule-payload-and-screening-data09", "name": "unique_transaction_identifier", "description": "Unique transaction identifier used where no account number exists.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] }, { "id": "travel-rule-payload-and-screening-data10", "name": "travel_rule_complete", "description": "Whether the required payload is complete for the applicable threshold.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] }, { "id": "travel-rule-payload-and-screening-data11", "name": "screening_status", "description": "Outcome of restrictive-measures screening for this transfer.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] }, { "id": "travel-rule-payload-and-screening-data12", "name": "screening_list_hit_ref", "description": "Reference to the hit that supports the screening decision.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] }, { "id": "travel-rule-payload-and-screening-data13", "name": "funds_frozen_indicator", "description": "Whether funds were frozen following screening.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025", "SRC-023" ] } ], "artifacts": [ { "id": "travel-rule-payload-and-screening-artifact01", "name": "FATF Recommendation 16 payment-transparency update (June 2025) originator and beneficiary information requirements", "description": "Revised recommendation text setting required originator and beneficiary information and chain responsibilities.", "media_or_form": [ "Standards update publication" ], "serial": false, "identity_strategy": "Identified by recommendation number and revision date.", "source_refs": [ "SRC-022" ] }, { "id": "travel-rule-payload-and-screening-artifact02", "name": "EU transfer-of-funds accompanying information and missing-data handling", "description": "Rules requiring payer and payee information to accompany transfers and requiring the payee's PSP to detect missing data.", "media_or_form": [ "Legislative summary (EUR-Lex)" ], "serial": false, "identity_strategy": "Identified by the regulation's CELEX number and article reference.", "source_refs": [ "SRC-025" ] } ], "questions": [ { "id": "travel-rule-payload-and-screening-q01", "text": "Which originator and beneficiary information accompanied this transfer, was it verified before execution, and is the payload complete for the applicable FATF or TFR threshold?", "kind": "constraint", "answer_data": [ "originator_name (string)", "originator_account_id (string)", "beneficiary_name (string)", "beneficiary_account_id (string)", "travel_rule_complete (boolean)", "verification_performed (boolean)" ] }, { "id": "travel-rule-payload-and-screening-q02", "text": "What sanctions or restrictive-measures screening status applies, was the transfer rejected, suspended or frozen, and which hit reference supports that decision?", "kind": "exception", "answer_data": [ "screening_status (enum)", "screening_list_hit_ref (string)", "funds_frozen_indicator (boolean)", "suspend_or_reject_reason (string)" ] }, { "id": "travel-rule-payload-and-screening-q03", "text": "Which payer and payee countries and addresses travelled with the message, and did any PSP in the chain sit outside the jurisdiction that required the full payload?", "kind": "spatial", "answer_data": [ "originator_address (object)", "beneficiary_country (iso-3166)", "chain_jurisdictions (iso-3166[])", "full_payload_required (boolean)" ] } ] } ] } ] } ] }, "functions": [ { "id": "register-payment-order", "name": "Register a payment order", "description": "Accept an instruction as a payment order, record actual and deemed receipt times, and assign or adopt the authoritative reference set.", "inputs": [ "Instruction payload", "Instructing party reference", "Channel and cut-off context", "Business day calendar reference" ], "outputs": [ "Registered payment aggregate", "Order receipt acknowledgement", "Deemed receipt timestamp", "Reference set" ], "preconditions": [ "The instruction contains no conditions to payment beyond time of payment", "A reimbursement path from the sender is identified", "The instructing party is entitled to instruct on the debtor account" ], "effects": [ "Starts every execution and notification deadline from the deemed receipt time", "Creates the first lifecycle event entry", "Fixes which references are authoritative and which are correlating" ], "source_refs": [ "SRC-002", "SRC-004", "SRC-003" ] }, { "id": "validate-payment-instruction", "name": "Validate a payment instruction", "description": "Check the instruction against the scheme profile, currency registry scale, party data profile and account identifier rules before acceptance.", "inputs": [ "Registered payment aggregate", "Payment scheme profile", "Party data payload profile", "Currency registry reference" ], "outputs": [ "Validation result set", "Account identifier validation report", "Blocking defect list" ], "preconditions": [ "A scheme profile for the classified payment type is available", "The currency code resolves in the governed registry" ], "effects": [ "Blocks acceptance where a mandatory scheme element is missing", "Records the validation depth actually achieved, including whether payee name was confirmed" ], "source_refs": [ "SRC-012", "SRC-009", "SRC-002" ] }, { "id": "authorise-payment", "name": "Authorise a payment", "description": "Capture consent in the agreed form, exercise authentication, and record evidence sufficient to answer a later unauthorised-transaction claim.", "inputs": [ "Registered payment aggregate", "Consent input", "Authentication factors", "Mandate reference where applicable" ], "outputs": [ "Authorisation state", "Authorisation evidence record", "Authentication outcome" ], "preconditions": [ "The consent form matches what the framework contract specifies", "The instrument used is in an active state" ], "effects": [ "Determines whether the payment is authorised for liability purposes", "Creates append-only evidence including failed attempts" ], "source_refs": [ "SRC-002", "SRC-013", "SRC-001" ] }, { "id": "screen-and-decide-acceptance", "name": "Screen and decide acceptance", "description": "Apply compliance, sanctions, fraud and limit checks, then accept, hold or refuse the order with a notifiable reason where lawful.", "inputs": [ "Validated payment aggregate", "Screening rule and list versions", "Applicable regime determination" ], "outputs": [ "Acceptance decision code", "Screening decision log", "Refusal notification" ], "preconditions": [ "Applicable regimes have been determined", "Screening lists in use have a recorded version" ], "effects": [ "Refusal must be notified at the earliest opportunity within the applicable execution period", "May create a non-disclosable hold whose true reason differs from the user-facing message" ], "source_refs": [ "SRC-002", "SRC-015", "SRC-014" ] }, { "id": "route-and-clear-payment", "name": "Route and clear a payment", "description": "Select the rail or correspondent chain, apply the settlement method per hop, and submit the payment into the clearing arrangement.", "inputs": [ "Accepted payment aggregate", "Reachability and rail capability data", "Liquidity position" ], "outputs": [ "Routing plan and actual route record", "Clearing cycle assignment", "Per-hop instructions" ], "preconditions": [ "The payee's agent is reachable on the selected rail", "The rail is open under its operating calendar or the order is scheduled" ], "effects": [ "Creates credit exposure between participants along the chain", "Binds the payment to a specific cycle and cut-off" ], "source_refs": [ "SRC-012", "SRC-010", "SRC-007" ] }, { "id": "settle-and-record-finality", "name": "Settle and record finality", "description": "Effect settlement in the applicable settlement asset, record settlement time, value date and availability, and assert the finality point under the governing rules.", "inputs": [ "Cleared payment aggregate", "Settlement operator confirmation", "Governing system rules reference" ], "outputs": [ "Settlement confirmation record", "Finality attestation", "Value date and availability values" ], "preconditions": [ "Sufficient liquidity or a settled net position exists", "The governing finality rule is identified for this rail" ], "effects": [ "Makes the payment irrevocable under system rules", "Discharges the underlying obligation subject to the recognised exceptions", "Triggers the payee's value dating and crediting duties" ], "source_refs": [ "SRC-007", "SRC-010", "SRC-005", "SRC-003" ] }, { "id": "report-payment-status", "name": "Report payment status", "description": "Emit or ingest a status with its reporting participant, leg, code set version and as-at time, and resolve conflicts between participants.", "inputs": [ "Payment aggregate", "Status message or observation", "Code set version" ], "outputs": [ "Payment status report", "Resolved aggregate status", "Conflict resolution note" ], "preconditions": [ "The status can be correlated to a payment through an echoed reference" ], "effects": [ "Appends to the lifecycle event log with distinct occurrence and observation times", "May supersede a previously reported status under a recorded precedence rule" ], "source_refs": [ "SRC-012", "SRC-011", "SRC-002" ] }, { "id": "revoke-or-recall-payment", "name": "Revoke or recall a payment", "description": "Attempt to stop a payment before irrevocability, or raise a recall or return request afterwards, and record the response.", "inputs": [ "Payment aggregate", "Requesting party reference", "Reason code", "Scheme window rules" ], "outputs": [ "Cancellation or recall request record", "Response outcome", "Recovered amount where any" ], "preconditions": [ "The requester is entitled to raise the request", "The applicable window is identified even if it has closed" ], "effects": [ "Before irrevocability, may prevent execution outright", "After finality, leaves the original payment intact and can only produce a new return payment" ], "source_refs": [ "SRC-002", "SRC-012", "SRC-004" ] }, { "id": "handle-dispute-and-error-claim", "name": "Handle a dispute or error claim", "description": "Open a case on a disputed or unauthorised payment, run the statutory clocks, apply provisional credit where required, gather evidence and determine liability.", "inputs": [ "Payment aggregate", "Claim as received", "Authorisation evidence record", "Applicable consumer rules" ], "outputs": [ "Dispute case file", "Provisional credit movement", "Liability allocation outcome", "Written explanation to claimant" ], "preconditions": [ "The claim was raised within the applicable notice window", "The clock start event is identified" ], "effects": [ "Creates hard deadlines for investigation and result reporting", "May reverse value provisionally before the determination is made", "Suspends scheduled deletion of the related evidence" ], "source_refs": [ "SRC-013", "SRC-002" ] }, { "id": "reconcile-and-emit-postings", "name": "Reconcile and emit postings", "description": "Match instruction, settlement confirmation and statement entry, classify breaks, and hand confirmed economic facts to the accounting model.", "inputs": [ "Payment aggregate", "Settlement confirmation record", "Payment confirmation and account statement", "Matching rules" ], "outputs": [ "Reconciliation result set", "Ledger posting reference", "Break list with ages and owners" ], "preconditions": [ "Statement sequence completeness has been checked", "Binding keys between instruction and entry are available" ], "effects": [ "Produces the accounting handoff without making posting-policy decisions", "Leaves unmatched items visible as ageing breaks rather than silently forcing a match" ], "source_refs": [ "SRC-012", "SRC-011", "SRC-007" ] }, { "id": "apply-retention-and-redaction", "name": "Apply retention and redaction", "description": "Enforce element-level retention bases, purge or redact expired elements without breaking append-only settlement and event records, and honour legal holds.", "inputs": [ "Payment aggregate", "Retention and access policy binding", "Legal hold flags", "Prohibited element list" ], "outputs": [ "Executed purge log entries", "Redacted record", "Retention compliance report" ], "preconditions": [ "A retention basis is recorded for every element class", "No legal hold or open dispute covers the elements in scope" ], "effects": [ "Removes restricted credential elements while preserving integrity proofs over the remainder", "Records the fact of removal permanently even after the data is gone" ], "source_refs": [ "SRC-014", "SRC-013", "SRC-002" ] }, { "id": "verify-payee", "name": "Verify payee", "description": "Match the instructed unique identifier to the payee name via scheme directory and record match, close-match or mismatch before the payer confirms execution.", "inputs": [ "Instructed payee unique identifier", "Instructed payee name", "Scheme directory or verification service" ], "outputs": [ "Match, close-match or mismatch result with the time of the check" ], "preconditions": [ "The payer has not yet confirmed the order for execution" ], "effects": [ "The verification result is recorded on the payment", "A payer decision to proceed after a non-match is recorded as an exception" ], "source_refs": [ "SRC-024", "SRC-021" ] }, { "id": "enrich-and-verify-travel-rule-data", "name": "Screen and enrich travel-rule data", "description": "Complete originator and beneficiary information, verify required fields, screen restrictive measures and block, freeze or release the order.", "inputs": [ "Originator and beneficiary information", "Applicable threshold and the jurisdictions in the chain", "Restrictive-measures screening service" ], "outputs": [ "Completeness assessment of the required payload", "Screening decision for this transfer" ], "preconditions": [ "The payment order exists and has not yet been sent to the rail" ], "effects": [ "The order is released, rejected, suspended or the funds frozen", "The screening decision and any hit reference are recorded" ], "source_refs": [ "SRC-022", "SRC-025" ] }, { "id": "initiate-mandate-based-debit", "name": "Initiate direct debit", "description": "Create a payee-initiated debit against a valid mandate, generating a distinct payment order per occurrence.", "inputs": [ "Mandate reference", "Payee instruction with amount and payer account identifier", "Sequence type for the occurrence" ], "outputs": [ "A distinct payment order for this direct-debit occurrence" ], "preconditions": [ "A mandate exists, is in force and covers this creditor, account and amount" ], "effects": [ "A pull payment order exists referencing the mandate", "The mandate sequence advances for the next occurrence" ], "source_refs": [ "SRC-016", "SRC-026" ] } ], "composition": [ { "target": "WM-ECO-016 Financial Transaction and Posting", "relation": "COMPOSE", "purpose": "A settled or reversed payment hands confirmed economic facts to the accounting model, which owns account selection, double-entry structure and period assignment. This model supplies the reconciled event, amounts, value dates and evidence references; it does not choose ledger accounts.", "required": true, "source_refs": [ "SRC-012", "SRC-011", "SRC-007" ] }, { "target": "WM-ECO-008 Invoice", "relation": "REFERENCE", "purpose": "A payment allocates against one or more invoices or claims, discharging them in whole or in part. Invoice line content, tax treatment and dunning state remain in the invoice model; only allocation, allocated amount and residual are held here.", "required": false, "source_refs": [ "SRC-005", "SRC-001" ] }, { "target": "WM-ECO-004 Money and Monetary Instrument", "relation": "REFERENCE", "purpose": "Currency identity, minor units, instrument forms and issuance are resolved by reference to the money model. This model never redefines a currency or an instrument form; it records which one a payment is denominated in and moves.", "required": true, "source_refs": [ "SRC-009", "SRC-001" ] }, { "target": "Account and Holding model (candidate sibling, not yet in registry)", "relation": "REFERENCE", "purpose": "Account identifiers, servicer relationships and balance effects are referenced rather than owned. Recorded as a gap: no registry entry currently exists, so account semantics are at risk of being absorbed here by default.", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "Person model", "relation": "REFERENCE", "purpose": "Natural persons occupying payer, payee or ultimate-party roles are resolved by identity reference and never inlined, keeping personal-data stewardship with the party model.", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] }, { "target": "Organization model", "relation": "REFERENCE", "purpose": "Payment service providers, agents, scheme operators and settlement operators are organizations resolved by reference, so that operator licensing and identity remain single-mastered outside this model.", "required": false, "source_refs": [ "SRC-001", "SRC-010" ] }, { "target": "Agreement and Obligation model", "relation": "REFERENCE", "purpose": "The framework contract governing the payment service, and the underlying obligation the payment discharges, live in the agreement model. Discharge conditions are evaluated here against terms defined there.", "required": false, "source_refs": [ "SRC-005", "SRC-002" ] }, { "target": "Dispute and Case Management model", "relation": "EXTEND", "purpose": "Chargeback and error-resolution workflow, evidence exchange with schemes and multi-payment cases extend beyond the payment aggregate. This model holds case linkage, deadlines and liability outcome only.", "required": false, "source_refs": [ "SRC-013", "SRC-002" ] }, { "target": "E-money token and crypto-asset transfer specialisation", "relation": "EXTEND", "purpose": "Transfers denominated in tokens referencing an official currency behave as payments but attract issuer authorisation, reserve and disclosure obligations under a separate regime; modelled as a specialisation so these do not contaminate the core aggregate.", "required": false, "source_refs": [ "SRC-015" ] }, { "target": "ISO 20022 payments message standard (pain, pacs, camt, remt business areas)", "relation": "ALIGN", "purpose": "Field-level equivalence with initiation, clearing and settlement, cash reporting and remittance message semantics. Alignment only: this model does not claim conformance and does not adopt message structure as its own semantics.", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] }, { "target": "ISO 4217 currency codes (SIX Maintenance Agency lists)", "relation": "ALIGN", "purpose": "Currency identity, numeric code and minor unit are carried by scheme and registry version rather than copied, so that currency changes such as a national euro adoption propagate by reference.", "required": true, "source_refs": [ "SRC-009" ] }, { "target": "CPMI-IOSCO Principles for Financial Market Infrastructures", "relation": "ALIGN", "purpose": "Settlement finality, money settlement and participant-default expectations are aligned to as external standards that constrain rail behaviour; the model records which principle a rail claims to meet without asserting compliance itself.", "required": false, "source_refs": [ "SRC-007" ] }, { "target": "W3C Payment Request API", "relation": "ALIGN", "purpose": "Interface-level alignment for order capture: payment method identifiers, currency-and-value amounts and the request state machine map onto this model's classification, amount and pre-acceptance lifecycle without becoming its semantics.", "required": false, "source_refs": [ "SRC-006" ] }, { "target": "PCI Data Security Standard", "relation": "ALIGN", "purpose": "Constrains what credential data this model may hold and how access, storage and disposal of card-borne elements are governed; alignment sets prohibitions rather than adding structure.", "required": false, "source_refs": [ "SRC-014" ] }, { "target": "Vercy access, stewardship and audit service models", "relation": "MIX-IN", "purpose": "Scoped access grants, steward assignment and usage auditing are mixed in rather than reimplemented, so that payment records inherit the Dimension's uniform access and audit surface.", "required": true, "source_refs": [ "SRC-014", "SRC-002" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must name a single owning package for the payment aggregate and declare, per rail it operates on, which participant is the system of record for settlement and finality facts; where the Dimension is not that participant, its records are declared derivative.", "The owning package must publish its scheme profile set (one per rail and rulebook version) and its code set registry (status, reason, purpose, charge bearer) with versions, because reason codes are only partially harmonised and are uninterpretable without a versioned code set identity.", "The owning package must declare the retention basis and access policy for each element class before any payment record is created, since credential and personal-data elements carry externally imposed prohibitions that cannot be applied retrospectively.", "The owning package must declare its business-day calendars and cut-off times per rail, as every statutory execution deadline is computed from a deemed receipt time that depends on them.", "The owning package must register the sibling models it resolves references against (money, party, invoice, accounting) and fail closed rather than inline a party or currency definition when a sibling is unavailable." ], "namespace_guidance": "Use a stable domain-scoped namespace under the economic navigation path (for example an authority-qualified IRI ending in a payment segment) that is independent of storage technology. Externally governed vocabularies keep their own namespaces and are referenced by scheme plus version, never re-minted: currency codes stay in the ISO 4217 registry namespace, message element names stay in the ISO 20022 namespace, scheme reason codes stay in their scheme namespace. Local terms coined by the Dimension must be clearly separated from imported terms so that an agent can tell at a glance whether a term is governed elsewhere.", "registry_links": [ "ISO 4217 currency code lists maintained by the ISO 4217 Maintenance Agency, referenced by list and amendment version", "ISO 20022 business areas and message definitions maintained by the ISO 20022 Registration Authority, referenced by business area code and message version", "Scheme and rail rulebook registries (for example the operator's own published message and format specifications), referenced by rulebook version and effective date", "Regulatory instrument registers for the applicable regimes, referenced by instrument identifier and consolidation date" ] }, "canon_and_patch": { "canonicalization_rules": [ "A payment is canonicalised around exactly one authoritative master identifier; all other references are stored as typed correlating aliases with their assigning participant, and are never promoted to master by convenience.", "Amounts are canonicalised as an exact decimal value plus a currency code, with scale validated against the governed minor unit of the referenced registry version; floating-point representation is prohibited and trailing-zero differences are not treated as value differences.", "All timestamps are canonicalised to RFC 3339 with seconds and an explicit offset; the stored value preserves the originating offset rather than silently normalising to UTC, because cut-off and business-day rules are local.", "Status and reason codes are canonicalised as a triple of code set identifier, code set version and code value; a bare code without its set version is treated as unresolved, not as a default-set code.", "Party and account data are canonicalised into their structured components where the source supplied structure; free-text concatenation of a structured address is a lossy projection and never the canonical form.", "Ordering of lifecycle events is canonicalised by source-assigned sequence where available, then by occurrence time, then by observation time, with the ordering basis recorded per entry." ], "patch_rules": [ "Settlement, finality and lifecycle event records are append-only: a correction is recorded as a new entry that supersedes an earlier one with a reason, never as an in-place edit, so the state known at any past moment stays reconstructible.", "Instruction-stage fields may be patched only before acceptance; after acceptance a change is either a scheme amendment with its own reference or a cancellation and reissue, and the model must record which occurred.", "A patch that changes amount, currency, payee or account identifier after acceptance is prohibited; such a change is a different payment and must be represented as one, linked to the original.", "Redaction and purge are expressed as patches that remove content while retaining the element's existence, class, removal time, basis and executing process, so that absence is distinguishable from never-present.", "Every patch carries the patching role, the basis, the occurrence time of the underlying fact and the observation time of the patch itself.", "Patches derived from a later-arriving participant status must not overwrite a status reported by a higher-precedence participant unless the precedence rule in force is recorded with the patch." ], "compatibility_rules": [ "Adding an optional element or a new code value is a compatible change; making an element required, narrowing a code set, or changing the meaning of an existing code is breaking and requires a new model version.", "Superseded scheme profiles, code set versions and retention policies are retained indefinitely so that historic payments remain interpretable under the rules in force when they occurred.", "Alignment to an external standard is versioned independently of this model; an upstream message version change does not force a model version change unless it alters semantics rather than structure.", "Consumers must tolerate unknown optional elements and unknown code values by preserving them verbatim rather than discarding them, since intermediary truncation is a known cause of reconciliation loss.", "A projection into any storage or interface format must be lossless for canonical elements or must publish its loss profile; a lossy projection may not be used as a system of record." ] }, "artifact_rules": { "identity_priority": [ "The authoritative master-system identifier assigned by the system of record for the fact in question takes absolute priority: for settlement and finality facts this is the settlement operator's or clearing system's own settlement reference; for a dispute it is the investigating institution's or scheme's case reference; for a statement it is the account servicer's statement identifier. This identifier is adopted verbatim and never re-minted.", "Where no master-system identifier exists, a governed global identifier or IRI issued under an externally maintained scheme is used, recorded together with its scheme name and version (for example a scheme-issued end-to-end transaction reference or a registered party identifier).", "Only where neither of the above exists does the adopting Dimension assign a UUID or ULID of its own, marked explicitly as Dimension-assigned so that a later authoritative identifier can supersede it without ambiguity.", "A date, a date-and-amount combination, a statement period or a filename is never an identifier; where a legacy source offers only these, a Dimension-assigned ULID is minted and the legacy string is retained as a non-identifying correlating attribute." ], "timestamp_rule": "All time values are recorded as RFC 3339 timestamps that include seconds and an explicit numeric offset or the literal Z; local wall-clock strings without an offset are rejected on ingest. Event time (when the act occurred at its source, such as when the payment order was received by the provider, when the rail settled it, or when finality arose) and observation or ingestion time (when the adopting Dimension learned of or recorded it) are stored as two separate fields whenever they differ, and neither may be derived from the other. Where a legally deemed time differs from the actual time (for example a post-cut-off order deemed received on the next business day), both the actual and the deemed value are retained with the rule that produced the deemed value. Durations and deadlines are stored as their computed absolute instants together with the rule and the calendar used, so that a deadline remains auditable after calendar data changes.", "serial_naming_rule": "Artifacts that form an ordered series (clearing cycle settlement instructions, account statements, lifecycle event log entries, reconciliation runs, retention policy versions) carry a strictly increasing integer sequence assigned by their issuing authority within a declared scope (rail, account, payment, or policy). Sequence numbers are gap-detectable, never reused and never derived from a calendar date; the date is recorded as a separate attribute. A gap in a received sequence is an explicit completeness defect that must be raised, not silently tolerated, and a duplicate sequence value from the same issuer is a conflict requiring resolution rather than an overwrite.", "integrity_rule": "Every artifact carries a content digest computed over its canonical form, the identifier of the issuing authority, and the observation time at which it was received. Append-only artifacts (event logs, screening logs, purge logs, settlement confirmations) additionally chain each entry to the digest of its predecessor within its sequence scope, so that removal or reordering is detectable. Redaction must preserve the chain by replacing content with a redaction marker that retains the original element digest where lawful; where the digest itself must be destroyed, the break is recorded explicitly as an integrity discontinuity with its basis rather than being concealed by recomputation." }, "policies": [ "Fail closed on unresolved identity: a payment whose authoritative master identifier cannot be established, or whose currency or party references cannot be resolved against their governing siblings, is held rather than processed on inferred values.", "Never infer finality. Finality is asserted only from an identified governing rule and an attesting authority; an absence of a failure message, a timeout, or a successful transmission acknowledgement must never be recorded as settled or final.", "Preserve the distinction between what a participant reported and what the Dimension concluded. Reported statuses are stored per participant; any aggregate status is a derived value with its precedence rule recorded and is never written back over a source report.", "Minimise before transmission and before storage: party and remittance content beyond what the selected rail requires is suppressed by default, and elements whose storage is externally prohibited after authorisation are never persisted, not even transiently in logs.", "Deadlines are first-class: every statutory or scheme deadline is materialised as an absolute instant with its start event, rule and calendar at the moment the clock starts, and breaches are recorded as facts rather than corrected retrospectively.", "Do not claim conformance to any external standard without evidence. Alignments are recorded as mappings with known losses and conflicts; a rail's own assertion of compliance is stored as that rail's claim, attributed to it.", "Do not execute a cross-border payment until travel-rule originator and beneficiary information required for the applicable threshold is complete and payer data has been verified.", "Authorization evidence and dual-control or SCA results must be retained with the payment; execution without recorded authorization is an exception event, not a normal create.", "Least-privilege access: only parties to the payment, their PSPs, the rail operator for its own rail, and competent authorities with a recorded legal basis may read non-aggregated payment data.", "Deletion of a settled payment is prohibited while a retention or legal hold applies; any later erasure or anonymisation emits an auditable deletion event that preserves the master-system identifier." ], "crud": { "read": [ "A party to a payment, or its authorised delegate, may read the payment's own record scoped to that party's role; a payer does not thereby gain the payee's counterparty data.", "Operational roles may read status, routing and reconciliation views for the payments they service, without access to credential or authentication-evidence content.", "Statistical consumers receive rail-level and period-level aggregates of volume, value and settlement latency with no party identification and with small-population suppression.", "Investigators and auditors may read the full record including screening and authorisation evidence under a recorded, time-bounded grant with a stated basis.", "Every read of a payment record is resolvable to a requesting identity, a scope and a basis; unattributable reads are not permitted." ], "create": [ "Only a role entitled to instruct on the debtor account, or a scheme-authorised initiator acting under a recorded mandate, may create a payment order.", "Settlement, finality, statement and status artifacts are created only by ingesting an identified issuing authority's record; the Dimension may not author these facts about itself where it is not the system of record.", "Creation requires the applicable scheme profile, currency registry reference and retention policy binding to be resolvable at the moment of creation.", "Dispute, return and recall cases may be created by an entitled claimant or participant, and creation immediately materialises the applicable deadlines." ], "update": [ "Instruction-stage attributes are updatable only before acceptance and only by the instructing role, with the prior value retained.", "After acceptance, no economic attribute is updated; changes are represented as amendments with their own reference, or as cancellation and reissue, and are linked to the original.", "Derived values (aggregate status, match state, deadline compliance) may be recomputed, but the source facts they derive from are never updated as a side effect.", "Corrections to ingested authority records are applied as superseding entries with the correcting authority and reason recorded, never as silent overwrites." ], "delete": [ "Payment records are not deleted while any retention basis, legal hold, open dispute or unexpired claim window applies to them.", "Element-level purge and redaction are used instead of record deletion, removing content while retaining element existence, class, removal time, basis and executing process.", "Credential elements whose retention is externally prohibited after authorisation are purged on a mandatory schedule that no business exception may extend.", "Deletion of an entire aggregate is permitted only on an explicit, recorded authority decision, and leaves a permanent tombstone carrying the master identifier, the deletion basis and the approving role.", "Where deletion would break an integrity chain, the discontinuity is recorded explicitly with its basis rather than concealed by recomputing digests." ] }, "roles": [ { "name": "Payment record steward", "responsibilities": [ "Own the payment aggregate's completeness, identity resolution and reference integrity within the Dimension", "Approve access grants beyond the default reader set and set their scope and expiry", "Decide precedence when participants report conflicting statuses, and record the rule applied" ] }, { "name": "Settlement and rail operations owner", "responsibilities": [ "Maintain scheme profiles, business-day calendars, cut-off times and code set versions per rail", "Ingest settlement confirmations and finality attestations from the systems of record and mark derivative records as such", "Manage liquidity, queueing and cycle participation, and raise completeness defects on missing statement or cycle sequences" ] }, { "name": "Compliance and financial crime owner", "responsibilities": [ "Determine applicable regulatory regimes per payment and record the determination basis and rule versions", "Own screening rule and list versioning and the disposition of holds, including non-disclosure handling", "Own record-keeping obligations and confirm that transferred originator and beneficiary data meets the applicable regime" ] }, { "name": "Dispute and claims owner", "responsibilities": [ "Run statutory clocks for error, chargeback and unauthorised-transaction claims and evidence deadline compliance", "Authorise provisional credit and record its movement and reversal", "Determine and record liability allocation and produce the written explanation supplied to the claimant" ] }, { "name": "Data protection and retention owner", "responsibilities": [ "Maintain element-level retention bases, purge schedules and legal holds", "Approve redaction techniques that preserve integrity chains and verify that prohibited elements are absent", "Review minimisation of party and remittance content transmitted to intermediaries" ] }, { "name": "Reconciliation and accounting liaison", "responsibilities": [ "Own three-way matching rules and break classification, ageing and escalation", "Operate the handoff to the accounting model without making posting-policy decisions inside this model", "Ensure corrections to payment facts are propagated as accounting corrections rather than silent restatements" ] } ], "access": { "default_rule": "Deny by default. Access to any payment record is granted only to an identified role with a stated basis and a scope no wider than needed: a party to the payment sees its own role-scoped view, operational roles see operational views without credential or authentication-evidence content, and everyone else receives only non-identifying aggregates. Grants are time-bounded and expire rather than persisting silently.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Investigatory and supervisory access may exceed the default scope under a recorded legal or regulatory basis, with the requesting authority, scope and period recorded and, where lawful, the affected party notified.", "Screening holds may require the true reason to be withheld from the payment service user even though refusal must normally be reasoned; the substitute message, the non-disclosure basis and the approving role are recorded internally.", "Claimants in a dispute are entitled to the evidence relied on in a readable form even where the underlying record is otherwise restricted; withheld items and their basis are recorded.", "Emergency operational access to resolve a settlement incident may be granted ahead of full approval, but expires automatically and is subject to mandatory after-the-fact review.", "Credential detokenisation is never covered by a general grant and always requires a separate, individually logged authorisation.", "Competent authorities with a recorded statutory basis may read specified findings or artifacts.", "Scheme operators may read R-transaction and recall fields required to operate the scheme.", "A PISP reads only payments it initiated, within consent scope and time.", "Public or research consumers may receive rail-level aggregates with no party, account or unique-identifier data." ], "audit_requirements": [ "Every read, grant, patch, purge and export is logged with requesting identity, scope, basis, occurrence time and observation time, in an append-only store separate from the payment records themselves.", "Access to authorisation evidence, screening logs and credential references is logged at element granularity, not merely at record granularity.", "Grants that expire unused, grants exercised outside their declared scope, and repeated near-scope reads are surfaced for periodic review by the payment record steward.", "Audit records are retained under their own retention basis, which is independent of and may outlast the retention of the payment data they describe.", "Aggregate and statistical exports record the suppression thresholds applied, so that re-identification risk can be assessed after the fact.", "Record actor, role, scope, purpose and RFC 3339 event time for every read of non-aggregated payment data.", "Record every authorization, screening decision, repair, recall, refund and deletion event with source-message hash.", "Make audit logs available to the steward and to competent authorities; do not use audit logs as a shadow payment ledger." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID and registry ID", "Authoritative identifier policy and system-of-record map per rail", "Timestamp and calendar policy, including deemed-time rules", "Code set registry and version pinning", "Access default rule and steward contact", "Retention and prohibited-element policy", "Sibling model resolution map and fail-closed behaviour", "Known conflicts, gaps and regional assumptions" ], "read_order": [ "Read AGENTS.md first and resolve Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before touching any payment data; if any is unresolvable, stop rather than proceed on defaults.", "Read the model specification to establish scope and, critically, the exclusions: confirm what belongs to the money, party, invoice and accounting siblings before creating or interpreting any element.", "Read the identifier policy and the system-of-record map to determine which identifier is authoritative for each fact class on the rails in use.", "Read the timestamp, calendar and cut-off policy before computing any deadline, deemed receipt time, value date or finality assertion.", "Read the code set registry and pin the versions in use, since status, reason, purpose and charge bearer codes are uninterpretable without a versioned set.", "Read the access default rule and the retention and prohibited-element policy before any read, export or persistence of credential, party or remittance content.", "Read the Processes URL to obtain the operational function contracts, then the Interface URL and Storage type URL only as projections; neither may be treated as the source of semantics.", "Read the recorded conflicts, gaps and regional assumptions last, and treat any structural node marked as a gap as unsupported rather than canonical." ] } }, "coverage": { "claim": "Base is the claude structure for Payment as an aggregate, extended with eight evidence-backed grok findings: travel-rule payload and screening, mandate and request-to-pay, exchange-of-value linkage on the payment leg, proxy/alias account addressing, verification of payee, instrument class including cash and cheque plus initiation direction, payment-order grain, and instant-transfer execution clocks. Coverage is bounded by the two consulted evidence sets and the regimes they cite (UK PSRs 2017, PSD2 and SEPA instruments, UCC Article 4A, Regulation E, FATF R.16 and the EU transfer-of-funds rules, PFMI and CPMI, ISO 20022, EPC SCT). Card-network chargeback rulebooks, cheque presentment law, national instant rails outside the EU, IBAN/BIC structural rules and CBDC or tokenised-deposit transfers are not covered and no universal completeness is claimed.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Master-versus-correlating reference distinction, the identifier priority order rooted in the system-of-record identifier, and the explicit finding that end-to-end references may be format-checked but not uniqueness-checked by the operator. Residual risk: schemes differ on which reference is authoritative, so the map is per-rail configuration rather than a fixed rule." }, { "dimension": "lifecycle", "status": "covered", "notes": "Receipt, acceptance or refusal, irrevocability, clearing, settlement, finality, return, recall and dispute are modelled as an append-only event history with permitted-transition checking. Legally deemed states (deemed receipt, deemed discharge) are held alongside observed states." }, { "dimension": "relationships", "status": "covered", "notes": "Role structure (payer, payee, initiating party, ultimate parties, ordered agent chain with per-hop sender and receiving bank), many-to-many payment-to-obligation allocation, and original-to-return linkage. Party entities themselves are referenced to sibling models, never inlined." }, { "dimension": "temporal", "status": "covered", "notes": "Actual versus deemed receipt, occurrence versus observation time, settlement time versus value date versus availability time, execution deadlines computed from deemed receipt, and dispute clocks materialised as absolute instants with their start event and calendar." }, { "dimension": "provenance", "status": "covered", "notes": "Every status, event and evidence item carries its reporting or issuing participant, source channel and an inferred-versus-reported flag; exchange rates and regulatory determinations carry quoting source and rule versions in force at determination time." }, { "dimension": "ownership", "status": "covered", "notes": "Charge-bearer allocation, liability allocation on disputes and unauthorised claims, and steward roles per record class. Stewardship of parties, money and postings is explicitly assigned outside this model." }, { "dimension": "validation", "status": "covered", "notes": "Amount scale validated against the governed minor unit, scheme-profile-driven mandatory element checks, identifier validation depth recorded (structural versus reachability versus payee-name confirmation), three-way reconciliation match state and statement sequence completeness." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with role-scoped views at bundle, layer, finding and artifact scope; element-granular logging for authorisation evidence, screening logs and credential references; detokenisation excluded from general grants." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Element-level retention bases rather than a blanket period; purge and redaction preserving element existence and integrity chains; mandatory purge for elements whose post-authorisation storage is externally prohibited; legal holds; tombstones on full deletion. Tension between evidential duties and minimisation is stated rather than resolved." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignment to ISO 20022 business areas, ISO 4217 currency lists, the W3C payment request surface and operator format rules, with explicit questions on cross-rail field loss, remittance truncation and reason-code mapping loss. Conformance is expressly not claimed." }, { "dimension": "classification", "status": "covered", "notes": "Instrument class, scheme, local instrument, service level, category purpose and purpose code, with the consequences of classification (deadlines, revocability, return rights) treated as derived from the rulebook rather than freely chosen." }, { "dimension": "authority and mandate", "status": "covered", "notes": "Consent form and scope, mandate references, authority of an initiating party acting for the payer, and the divergence between operational finality assertion and the legal moment of payment." }, { "dimension": "settlement finality", "status": "covered", "notes": "Modelled as a legally determined state with an identified governing rule, an attesting participant, and the four recognised exceptions to discharge of the underlying obligation; operational and legal finality points are stored separately because they can differ." }, { "dimension": "exceptions and reversal", "status": "covered", "notes": "Refusal, revocation, amendment, return, return request and refusal of it, reversal, refund, chargeback, error resolution and unauthorised-transaction claims are separated with distinct references, reason code sets and windows." }, { "dimension": "measurement", "status": "covered", "notes": "Instructed versus settled amount divergence, charge attribution, value-dating float, queue duration, reconciliation break ageing and deadline compliance are all expressed as measurable quantities with attribution." }, { "dimension": "security", "status": "covered", "notes": "Authentication evidence, credential tokenisation, prohibited post-authorisation elements, integrity chaining over append-only records and explicit recording of integrity discontinuities." }, { "dimension": "privacy", "status": "covered", "notes": "Minimisation of party and remittance content before transmission, exposure of remittance content to intermediaries, jurisdiction and data-residency touchpoints, and redaction against append-only records." }, { "dimension": "spatial", "status": "covered", "notes": "Handled as jurisdictional and settlement-location touchpoints and operating calendars rather than geometry; no geographic coordinate structure is claimed, since no consulted source supports one for payments." }, { "dimension": "cash and physical instruments", "status": "gap", "notes": "Cash payments, over-the-counter deposits and physical instruments such as cheques are within the statutory definition of a payment transaction but are only weakly represented here: no consulted primary source detailed cheque clearing, presentment or physical handling, so no dedicated finding was created rather than inventing one." }, { "dimension": "pricing and interchange economics", "status": "not-applicable", "notes": "Charge bearer allocation and charge attribution are in scope, but interchange fee determination, scheme fee schedules and merchant pricing are economic arrangements governed by separate instruments and belong to a pricing or scheme-economics sibling." } ], "known_omissions": [ "Cheque and other paper instrument clearing, presentment, dishonour and truncation are not modelled as findings; the execution-time rules consulted acknowledge paper-initiated orders but no consulted source detailed the paper clearing lifecycle.", "Cash payments and over-the-counter transactions are within the statutory definition of a payment transaction but have almost no dedicated structure here, because none of the consulted primary sources described them operationally.", "Interchange, scheme fees and merchant pricing are excluded; only charge bearer allocation and observed charges are modelled.", "Standing orders, direct debit mandate registration and mandate amendment lifecycles are referenced but not decomposed; mandate management plausibly warrants its own sibling model.", "Request-to-pay and drawdown flows are visible in the operator source consulted but are not given a dedicated finding, as no primary source describing their full lifecycle was successfully retrieved.", "Payment-versus-payment and delivery-versus-payment linked settlement are named as an international principle area but not decomposed, because the underlying principles document could not be text-extracted.", "The CPMI glossary PDF could not be text-extracted during this research, so canonical definitions of clearing, settlement and settlement asset are supported by other sources and the glossary is cited only as the terminology register.", "The EU payment services directive and the settlement finality directive could not be retrieved from the official EU repository during this research; the UK transposing instrument is used as the retrievable statutory proxy, which may diverge in detail from the EU text.", "No source was successfully retrieved for IBAN or BIC structural rules, so account identifier validation is modelled generically by scheme rather than with scheme-specific check rules.", "Anti-money-laundering travel rule detail could not be retrieved from the standard-setter directly; transferred originator and beneficiary data is modelled as a requirement without the specific thresholds or element lists.", "Visa, Mastercard and other card-scheme chargeback operating regulations and ISO 8583 authorization/clearing field maps were not retrieved as primary texts.", "National instant systems (FedNow, PIX, UPI, Faster Payments, PromptPay and others) are not modelled beyond EU instant SCT and generic CPMI fast-payment timing.", "Cheque presentment law and cash-till operations are classified as instrument classes only.", "CBDC, tokenised deposits and programmable escrow remain emerging; only CPMI-IOSCO stablecoin-arrangement PFMI guidance is acknowledged, not fetched in full.", "Correspondent banking cover-method edge cases and in-house multilaterally nested nostro chains are sketched, not exhausted.", "W3C Payment Request API and merchant checkout objects are out of this transfer model.", "Exact AML retention periods vary by jurisdiction and are not encoded as a single number.", "Person/org KYC attributes, sanctions list content and FX market-rate histories are sibling concerns." ], "conflicts": [ "The duty to give reasons for refusing a payment order conflicts with non-disclosure obligations arising from sanctions and financial-crime holds. The model records an internal true reason and a substitute user-facing message rather than pretending the tension does not exist.", "Operational finality asserted by a settlement system and the legal moment of payment under funds-transfer law need not coincide; the model stores both and requires the governing rule to be named per purpose rather than declaring one authoritative.", "Where charges are deducted in transit, the amount received differs from the amount instructed, yet the underlying obligation may still be treated as discharged in the full instructed amount. Charge accounting and discharge accounting are therefore modelled as separate facts.", "Evidential retention duties (claim windows measured in months, investigation and disclosure duties) pull against data minimisation and against externally imposed prohibitions on storing certain credential elements. This is resolved by element-level retention bases, not by a single retention period.", "Consumer error-resolution timeframes and payment-services execution and refund timeframes are drawn from different regimes with different clock-start events; a payment can be simultaneously subject to both with incompatible deadlines, so each deadline is materialised with its own rule and start event.", "Append-only integrity chaining conflicts with hard deletion obligations. The model prefers redaction preserving element digests, and requires that an unavoidable break be recorded as an integrity discontinuity rather than concealed.", "Registry purpose says a payment discharges or changes a monetary obligation, while PSD2 defines a payment transaction irrespective of any underlying obligations. This model records optional discharge links and allows transfers with no recorded claim (gifts, cash-out, errors).", "PSD2 makes a payment order irrevocable after time of receipt subject to listed exceptions, UCC 4A allows cancellation before acceptance by the beneficiary's bank, and EPC SCT permits post-settlement recall in limited cases. Lifecycle must store which legal regime governs.", "UCC 4A-207 name-versus-account-number reliance can diverge from EU verification-of-payee match-before-pay.", "ISO 20022 transaction status codes and EPC R-transaction reason codes overlap but are not identical vocabularies; treat as aligned enumerations, not one code list.", "Instant 10-second statutory SLA (EU Regulation 260/2012 as amended) is stricter than PSD2 D+1 execution for ordinary credit transfers and may differ from EPC SCT Inst scheme timings.", "ISO 20022 implementations remain inconsistent across jurisdictions; CPMI d218 exists because fragmentation undercuts the standard. Alignment is not conformance." ], "regional_assumptions": [ "Statutory definitions and execution-time rules are taken from a United Kingdom transposing instrument as the retrievable proxy for the European payment services regime; other jurisdictions have materially different definitions, deadlines and liability caps, and the specific monetary caps and day counts must not be treated as universal.", "Funds-transfer definitions and the discharge rule are taken from a United States uniform commercial law text; its adoption and amendment state varies by state and it does not apply outside its jurisdiction.", "Consumer error-resolution deadlines are taken from a United States federal consumer regulation and apply to electronic fund transfers within its scope only.", "Real-time gross settlement behaviour, immediate finality and the operating calendar are taken from one euro-area system; other rails settle on deferred net cycles with materially different finality points and calendars.", "One operator's ISO 20022 usage (mandatory end-to-end reference, structured address minimums, charge bearer codes) is treated as evidence of what rails can require, not as a universal requirement; each rail's own profile governs.", "Token-denominated transfer obligations are taken from a European regulation with a phased application timeline; equivalent regimes elsewhere differ in scope and timing.", "No assumption is made that any single currency, calendar, language or address format is default; currency, calendar and address structure are always resolved by reference.", "IBAN as the default unique identifier is an EEA/SEPA assumption; other regions use national account numbers plus routing codes.", "UCC Article 4A governs US wholesale funds transfers and Fedwire-like credit transfers, not all US consumer ACH products (NACHA).", "Settlement Finality Directive protection applies to designated systems in the EEA and equivalent regimes, not globally.", "FATF R.16 enhanced data at USD/EUR 1,000 is a FATF threshold; local implementation may differ.", "Instant 24/7/365 with 10-second availability is an EU instant-credit-transfer rule, not a universal rail property.", "Address structured/hybrid/unstructured transition dates in EPC SCT (unstructured address no longer permitted from 15 November 2026 per 2025 rulebook v1.1) are SEPA-scheme specific." ], "adversarial_checks": [ "Counterexample sought for treating settlement as sufficient for discharge: funds-transfer law supplies four exceptions under which the underlying obligation is not discharged despite acceptance by the beneficiary's bank, so discharge is modelled as conditional and separately stated rather than as a consequence of settlement.", "Counterexample sought for a single global payment status: operator status reporting is per participant and per leg, and a payment can be settled on one leg while pending on another, so a single authoritative status field was rejected in favour of participant-scoped reports plus a derived value with a recorded precedence rule.", "Counterexample sought for treating a payment reference as a reliable primary key: the operator source states that format is checked but uniqueness is not, so end-to-end references are demoted to correlating aliases and the system-of-record identifier is made authoritative.", "Counterexample sought for a single blanket retention period: card security standards prohibit retaining some elements after authorisation while consumer claim windows require others to be kept for many months, so per-element retention bases were adopted and a uniform period was rejected.", "Attractive but unsupported structure rejected: a currency and exchange-rate catalogue, an account and balance sub-model, and a ledger posting structure were all considered and excluded because they duplicate sibling models; only references and the composition boundary are retained.", "Attractive but unsupported structure rejected: a universal harmonised status and reason-code enumeration was considered and rejected, because reason code sets are scheme-governed and only partially harmonised; codes are therefore stored as code set identifier, version and value.", "Boundary stress-tested on the money-versus-transfer line: a token-denominated transfer behaves like a payment but attracts issuer authorisation and reserve obligations, so it is modelled as an EXTEND specialisation rather than as a core variant, preventing regime-specific obligations from leaking into every payment.", "Retrieval failure treated as a gap rather than filled from memory: several intended primary sources (the EU directives, the standard-setter's wire transfer recommendation, the glossary and principles PDFs) could not be retrieved or text-extracted, and the affected areas are recorded as known omissions instead of being asserted from background knowledge.", "Money-versus-transfer: currency catalogue, cash/deposit stock, issuance and balances were excluded and pointed at WM-ECO-004; only amount snapshots and instrument references remain here.", "Invoice and ledger duplication: invoices stay WM-ECO-008 via remittance references; journal postings stay WM-ECO-016 via COMPOSE, not as extra payments.", "Conformance claim avoided: ISO 20022, PFMI, PSD2, UCC 4A, FATF and EPC are recorded as ALIGN or regime-conditional, never as universal conformance.", "Rare lifecycles included with primary support (instant timeout, cover method, mandate, request-to-pay, recall after settlement, unauthorized refund) and marked as gaps where primary text was not fetched (card chargeback codes, CBDC programmes)." ] }, "researchAdjudication": { "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "Both providers agree on the same outer boundary (money-as-instrument to WM-ECO-004, invoice to WM-ECO-008, postings to WM-ECO-016, parties by reference only), so the disagreement is only about entry kind. The base treats Payment as an aggregate with an internal ordered event history, mutable status per leg, and dependent records (order, authorisation evidence, settlement confirmation, returns, dispute case, statements) that are addressed and retained separately; grok's 'event' framing cannot carry those dependent records or the per-leg status divergence it itself models. Aggregate is therefore adopted and grok's evented view is preserved as the lifecycle-event-history projection inside the base, not as the entry kind. The account/holding neighbour remains an unresolved registry boundary and is carried forward as declared by the base rather than silently absorbed." }, "decisions": [ { "concept": "Base provider selection", "disposition": "claude adopted as base", "rationale": "Its neighbour notes name relation types (COMPOSE for postings, EXTEND for card and token transfers), flag the missing account/holding sibling as an unresolved boundary instead of absorbing it, and its omissions are declared rather than filled from memory. Grok's boundaries are sound but its value/rail bundle cuts across the lifecycle bundle the base keeps whole." }, { "concept": "Entry kind, aggregate versus event", "disposition": "aggregate retained; grok's event view mapped to lifecycle-event-history", "rationale": "Dependent records with independent retention and addressing (authorisation evidence, settlement confirmation, dispute case, statements) and per-leg status divergence cannot hang off a single event record, and grok models both of those itself." }, { "concept": "Payment with no recorded underlying obligation", "disposition": "accepted as a scope clarification on the base purpose statement", "rationale": "Grok correctly notes PSD2 defines a payment transaction irrespective of any underlying obligation. The base already models discharge as conditional and allocation as many-to-many, so obligation linkage is marked optional rather than constitutive; gifts, cash-out and error payments remain in scope." }, { "concept": "Travel-rule payload and screening", "disposition": "accepted into compliance-access-and-retention", "rationale": "Closes a gap the base itself declared, with tier-1 FATF and EU transfer-of-funds evidence carrying specific accompanying fields, verification duty and missing-data handling." }, { "concept": "Mandate and request-to-pay", "disposition": "accepted into consent-and-authorisation", "rationale": "Both were base known omissions; grok supplies the ISO 20022 mandate and creditor-payment-activation message evidence that gives pull authority a home distinct from per-payment consent." }, { "concept": "Exchange-of-value linkage (PvP and DvP)", "disposition": "accepted into settlement-and-finality, payment leg only", "rationale": "Fills a declared base omission from PFMI Principle 12 while preserving the base exclusion of securities and asset legs; only the conditionality on this leg's finality is taken." }, { "concept": "Proxy and alias account addressing", "disposition": "accepted into accounts-and-instruments", "rationale": "Wholly absent from the base, which models only the provider-designated unique identifier, and materially real for modern retail rails; evidenced by the EPC 2025 SCT rulebook alias and proxy definitions." }, { "concept": "Verification of payee", "disposition": "accepted into accounts-and-instruments", "rationale": "A separately regulated pre-execution control with its own match outcomes, payer-override exception and reuse limits, reduced in the base to one validation-depth question; also the safeguard for the accepted proxy-addressing structure." }, { "concept": "Instrument class including cash and cheque, and initiation direction", "disposition": "accepted into identification-and-typing", "rationale": "Addresses the base's declared cash and physical-instrument gap and adds the push/pull/third-party/request-to-pay axis the base classification finding does not carry, without displacing scheme and service-level classification." }, { "concept": "Payment order grain (order versus bulk file versus interbank transaction)", "disposition": "accepted into order-receipt-and-revocability", "rationale": "The aggregate entry kind is unusable without a stated grain; grok supplies the UCC and PSD2 order definitions and the rule that each transfer in a bulk is a separate payment." }, { "concept": "Instant execution clocks and settlement lag", "disposition": "accepted into settlement-and-finality", "rationale": "The base deemed-receipt and business-day model mis-states instant transfers, where receipt is calendar-independent and availability is due in seconds; grok's evidence qualifies the base deadline finding rather than duplicating it." }, { "concept": "Grok payer/payee roles and agent-and-intermediary-chain findings", "disposition": "rejected as duplicative", "rationale": "The base payer-payee-and-agent-roles finding already carries functional role definitions, ultimate parties, the ordered agent chain and per-hop sender/receiving bank; the only unique element, the cover-versus-serial question, is already covered by the base settlement-method question." }, { "concept": "Grok rail-and-clearing-method finding", "disposition": "rejected as duplicative", "rationale": "The base splits the same content across rail-selection-and-routing-chain and clearing-cycle-netting-and-settlement-arrangement, including settlement asset, gross versus net and settlement method per hop." }, { "concept": "Grok unauthorized-refund-and-chargeback finding", "disposition": "rejected; card chargeback and third-party-provider liability deferred", "rationale": "The base disputes finding is stronger on clocks, provisional credit and liability allocation, and grok itself records that no card-scheme rulebook was retrieved, so the addition would import an acknowledged evidence gap as structure." }, { "concept": "Grok status-inquiry-and-advice and provenance-stewardship-and-retention findings", "disposition": "rejected as duplicative", "rationale": "The base already models status reporting with code-set identity and reporting participant, confirmations and statements with issuer attestation, and element-level retention with steward assignment and legal holds." }, { "concept": "Layer merge strategy", "disposition": "merge accepted grok findings into existing base layers; no parallel service bundle", "rationale": "Every accepted addition maps onto an existing base layer, so keeping grok's bundle skeleton alongside would create competing homes for the same concepts and break the base's single lifecycle bundle." } ], "publicationHolds": [ "Source verification hold: every accepted URL must be fetched live and version-pinned before publication, in particular grok SRC-006 (EPC 2025 SCT rulebook v1.1), SRC-009 (consolidated Regulation 260/2012 of 8 April 2024) and SRC-007 (FATF R.16 update of 18 June 2025), and base SRC-012 and SRC-010 whose operator pages change without notice.", "Source deduplication hold: the two providers cite several of the same underlying documents at different URLs (CPMI glossary d00b versus glossary.pdf, PFMI d101 versus the principle index, UCC 4A-103/4A-406 versus 4A-104, ISO 20022 business areas versus message definitions). These must be collapsed into single canonical source entries with one version pin before the draft is published, otherwise the citation count overstates independent support.", "Authority-tier hold: grok SRC-010 is a EUR-Lex summary page, not the legal text. Any element list, threshold or verification duty taken from it must be re-grounded on the regulation itself before the travel-rule finding is published.", "Retrieval-failure hold: the base declares that the PFMI and CPMI glossary PDFs, PSD2 and the settlement finality directive could not be extracted, and used a UK transposing instrument as proxy. Grok's sources partially cover these; each previously unsupported claim must be re-checked against the newly available text rather than assumed to be now sourced.", "Multi-profile validation hold: the merged structure has not been validated across domain profiles. Before publication it must be exercised against at least SEPA including instant, US wire and ACH with Regulation E consumer scope, a card acquiring flow, and one non-Western instant rail, since revocability, finality, verification and refund rules diverge on each.", "Regime-scoping hold: all specific caps, day counts and thresholds (UK PSR execution and liability rules, Regulation E ten/forty-five/sixty-day clocks, the FATF USD/EUR 1,000 enhanced-data threshold, the EU ten-second SLA, the EPC unstructured-address end date of 15 November 2026) must be published as regime-scoped facts with their instrument named, never as universal payment properties." ], "deferredResearch": [ "Card scheme chargeback reason catalogues, dispute cycles and ISO 8583 authorization and clearing semantics: neither provider retrieved a primary card-network rulebook, so post-settlement card dispute structure stays a declared gap rather than inferred structure.", "Payment initiation service provider and other third-party-provider initiation: consent scope, access-token lifecycle and expiry, and the ASPSP-versus-PISP burden of proof and liability split. Present only in grok and only via the directive; needs the strong-customer-authentication technical standards as primary text.", "Cheque presentment, dishonour and truncation, and cash over-the-counter operations: both providers classify these as instrument classes only, with no operational lifecycle sourced.", "National instant and retail rails outside the EU (FedNow, UPI, PIX, Faster Payments) and non-IBAN account identifier structures, plus IBAN and BIC structural validation rules, which neither provider retrieved.", "Registry decision on the missing Account and Holding sibling model: the base records it as an unresolved boundary, and value date, availability and balance effects cannot be finally allocated until that neighbour exists.", "Tokenised deposit, e-money token and CBDC transfers: the base cites MiCA for the EXTEND specialisation, grok flags CPMI-IOSCO stablecoin-arrangement guidance as unfetched; the specialisation needs its own sourced pass before it is asserted.", "Jurisdictional retention periods for payment and authorisation evidence under anti-money-laundering law, which grok correctly declines to encode as a single number." ] }, "statistics": { "sources": 26, "bundles": 6, "layers": 13, "findings": 35, "questions": 124, "artifacts": 37, "functions": 14 } }