Payment

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.

Questions

1. Which single identifier is the authoritative master reference for this payment, and which system of record assigns it?identity
   Expected answer

   • Master identifier value
   • Assigning system or scheme name
   • Assignment scope (global, scheme, participant)
2. How are initiating-party, instructing-agent, clearing-system and end-to-end references held distinct while remaining correlatable?relationship
   Expected answer

   • Reference type
   • Reference value
   • Assigning participant reference
   • Correlation role (authoritative, alias, leg-local)
3. Who verifies that the end-to-end reference is unique, and what happens when uniqueness is only format-checked?validation
   Expected answer

   • Uniqueness check performed (boolean)
   • Checking party
   • Duplicate detection outcome
   • Collision handling rule
4. Which references must intermediaries pass through unaltered, and which may they replace on their own leg?interoperability
   Expected answer

   • Pass-through obligation flag per reference type
   • Governing scheme rule reference
   • Observed alterations across legs

Artifacts

• Payment identifier crosswalkA 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.

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.

Questions

1. What instrument class and scheme does this payment belong to, and which rulebook version therefore governs it?classification
   Expected answer

   • Instrument class code
   • Scheme or clearing system identifier
   • Rulebook version reference
2. Which execution deadline, revocability rule and return right follow from the chosen classification rather than from party agreement?constraint
   Expected answer

   • Derived execution deadline
   • Derived revocability rule
   • Derived return window
   • Source of the rule (statute, rulebook, contract)
3. On what basis was this scheme selected over an eligible alternative, and who made that choice?decision
   Expected answer

   • Selection criteria applied
   • Rejected alternatives
   • Deciding party reference
   • Decision timestamp
4. How does this classification map onto an external payment method identifier used by an ordering channel?interoperability
   Expected answer

   • External payment method identifier
   • Mapping confidence
   • Unmapped residual attributes

Artifacts

• Payment scheme profileA 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.

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.

Questions

1. Is this payment a credit transfer, direct debit, card, e-money, cheque, cash or another instrument class, and is it instant or non-instant?classification
   Expected answer

   • instrument_class (enum)
   • instant_indicator (boolean)
   • local_instrument (string)
2. 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?relationship
   Expected answer

   • initiation_direction (enum)
   • initiating_party_role (enum)
   • pisp_party_ref (party-ref)
3. 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?constraint
   Expected answer

   • scheme_id (string)
   • service_level (string)
   • domestic_or_cross_border (enum)
   • payer_psp_jurisdiction (iso-3166)
   • payee_psp_jurisdiction (iso-3166)

Artifacts

• CPMI payments statistics methodology — payment instrument types and domestic versus cross-border rulesMethodology text enumerating the payment instrument classes and the domestic versus cross-border rule used for statistics.
• SEPA Regulation consolidated definition of instant credit transfer and payment initiation channelConsolidated legislative text defining instant credit transfer and how such orders are initiated.

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.

Questions

1. Is the amount fixed at instruction time or determinable later, and what rule determines it?definition
   Expected answer

   • Determinacy flag
   • Determination rule text or reference
   • Determination time
2. How is the amount validated against the governed minor unit of its currency, and what is done with excess precision?validation
   Expected answer

   • Currency alphabetic code
   • Minor unit from registry
   • Scale of submitted value
   • Rejection or rounding rule applied
3. Where the settled amount differs from the instructed amount, what accounts for the difference?measurement
   Expected answer

   • Instructed amount
   • Settlement amount
   • Difference cause code (conversion, charges, partial)
   • Difference value

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.

Questions

1. Which party applied the exchange rate, from which quoting source, and at what quotation time?provenance
   Expected answer

   • Conversion party reference
   • Rate source name
   • Quotation timestamp
   • Rate type (contractual, indicative, scheme)
2. Was the applicable rate disclosed to the payer before the order became irrevocable?authority
   Expected answer

   • Disclosure made (boolean)
   • Disclosure timestamp
   • Disclosed rate value
   • Disclosure channel
3. What margin separates the applied rate from the reference rate, and how is it attributed?measurement
   Expected answer

   • Applied rate
   • Reference rate
   • Margin value or percentage
   • Margin-receiving party reference

Artifacts

• Exchange rate quote recordAn 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.

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.

Questions

1. Which charge bearer arrangement applies, and does it permit deduction from the transferred principal?ownership
   Expected answer

   • Charge bearer code
   • Deduction permitted (boolean)
   • Governing rule reference
2. Which agent levied each charge, in what amount and currency, and on which leg?measurement
   Expected answer

   • Charging agent reference
   • Charge amount
   • Charge currency
   • Leg identifier
3. If charges were deducted in transit, is the underlying obligation still treated as discharged in the full instructed amount?exception
   Expected answer

   • Deducted total
   • Discharge treatment code
   • Beneficiary demand raised (boolean)
   • Originator response

Artifacts

• Charge breakdown statementAn 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.

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.

Questions

1. Which entity occupies each payment role, and does any entity occupy more than one role?relationship
   Expected answer

   • Role code
   • Entity reference
   • Role overlap flag
2. Do the ultimate debtor or ultimate creditor differ from the account-holding payer and payee, and why?composition
   Expected answer

   • Ultimate debtor reference
   • Ultimate creditor reference
   • Divergence reason
   • On-behalf-of arrangement reference
3. What is the ordered sequence of agents, and which agent is the sender and receiving bank on each hop?composition
   Expected answer

   • Hop index
   • Sending agent reference
   • Receiving agent reference
   • Hop instruction reference
4. On what authority does the initiating party act where it is not the payer itself?authority
   Expected answer

   • Authority basis code
   • Mandate or power reference
   • Authority validity window

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.

Questions

1. What is the minimum party data set the selected rail requires, and is every mandatory element present?requirement
   Expected answer

   • Required element list
   • Present element list
   • Missing element list
   • Rail rule reference
2. Is the party address supplied in structured form, and which structured components are populated?validation
   Expected answer

   • Structured address flag
   • Country code
   • Town name
   • Other populated components
3. Which carried party attributes exceed what the rail requires, and on what basis are they transmitted?privacy
   Expected answer

   • Excess attribute list
   • Transmission basis
   • Recipient scope
   • Suppression option available (boolean)
4. Which identifier scheme is used to identify each party, and is the scheme externally governed?interoperability
   Expected answer

   • Identifier scheme name
   • Identifier value
   • Scheme governance body
   • Scheme version

Artifacts

• Party data payload profileA 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.

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.

Questions

1. Which supplied value is designated as the unique identifier by the provider, and which other account data is advisory only?identity
   Expected answer

   • Unique identifier value
   • Identifier scheme
   • Advisory field list
   • Designating provider reference
2. What happens when the account name and the unique identifier disagree, and who bears the resulting loss?exception
   Expected answer

   • Mismatch detected (boolean)
   • Verification result code
   • Liability allocation
   • Recovery effort record reference
3. Was the identifier only structurally validated, or was existence and ownership confirmed with the receiving institution?validation
   Expected answer

   • Validation level code
   • Validating party reference
   • Validation timestamp
   • Validation outcome

Artifacts

• Account identifier validation reportA 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.

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.

Questions

1. Which device or agreed procedure constitutes the payment instrument used here, and who issued it?definition
   Expected answer

   • Instrument type code
   • Issuing provider reference
   • Instrument reference or token
   • Personalisation basis
2. Which credential elements may be stored after authorisation, and which must never be retained?security
   Expected answer

   • Storable element list
   • Prohibited element list
   • Protection method applied
   • Governing standard reference
3. What is the current state of the instrument, and does its expiry or suspension invalidate pending payments?lifecycle
   Expected answer

   • Instrument state code
   • State effective time
   • Effect on pending payments
   • Replacement instrument reference
4. Which roles may resolve a stored token back to the underlying credential, and under what control?access
   Expected answer

   • Authorised role list
   • Detokenisation control
   • Approval requirement
   • Access log reference

Artifacts

• Instrument credential recordA 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.

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.

Questions

1. What unique identifier, IBAN or other account scheme identifier was used to identify the payer account to debit and the payee account to credit?identity
   Expected answer

   • payer_unique_identifier (string)
   • payee_unique_identifier (string)
   • account_scheme (enum)
   • payer_account_ref (account-ref)
   • payee_account_ref (account-ref)
2. 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?interoperability
   Expected answer

   • payee_proxy_type (enum)
   • payee_proxy_value (string)
   • resolved_account_identifier (string)
   • resolution_service (string)
3. 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?constraint
   Expected answer

   • name_number_match_status (enum)
   • relied_on_identifier (enum)
   • mismatch_handling_rule (string)

Artifacts

• EPC 2025 SCT rulebook alias and proxy definitions and account identification practiceScheme rulebook clauses defining aliases and proxies and how accounts are identified for SEPA credit transfers.

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.

Questions

1. Was verification of payee or confirmation of payee performed, what match result was returned, and at what event time?evidence
   Expected answer

   • vop_performed (boolean)
   • vop_result (enum)
   • vop_checked_at (rfc3339)
   • vop_service_id (string)
2. 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?exception
   Expected answer

   • payer_proceeded_despite_mismatch (boolean)
   • payer_confirmation_at (rfc3339)
   • stp_exception_code (string)
3. Which directory or scheme API provided the match, and can the result be reused across rails or only within this scheme?interoperability
   Expected answer

   • vop_service_id (string)
   • result_portability (enum)

Artifacts

• EU instant credit-transfer payee-verification overlay on Regulation 260/2012 as amendedLegislative overlay requiring a check of alignment between the payee's unique identifier and name before execution.

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.

Questions

1. In what agreed form was consent given, and does that form cover this specific payment or a series?authority
   Expected answer

   • Consent form code
   • Consent scope (single, recurring, series)
   • Consenting party reference
   • Consent timestamp
2. What authentication evidence exists to show the payer authorised this payment, and where is it retained?evidence
   Expected answer

   • Authentication method code
   • Authentication outcome
   • Evidence artifact reference
   • Retention location
3. Within what period may the payer still claim the payment was unauthorised, and when does that period start?temporal
   Expected answer

   • Claim window duration
   • Window start event
   • Window start timestamp
   • Governing rule reference

Artifacts

• Authorisation evidence recordA 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.

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.

Questions

1. Was the order accepted, refused, held or declined, and which of these did the payer actually experience?decision
   Expected answer

   • Decision outcome code
   • Decision timestamp
   • Deciding participant reference
   • User-visible outcome
2. Was refusal notified within the applicable execution period, with reasons and correction instructions?process
   Expected answer

   • Notification timestamp
   • Reason given (boolean)
   • Reason text or code
   • Correction guidance provided (boolean)
3. Where a screening hold prevents disclosure of the true reason, how is the tension with the duty to give reasons resolved?exception
   Expected answer

   • Non-disclosure basis reference
   • Substitute message given
   • Internal true reason code
   • Approving role

Artifacts

• Screening and decision logAn 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.

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.

Questions

1. 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?lifecycle
   Expected answer

   • mandate_id (string)
   • mandate_status (enum)
   • sequence_type (enum)
   • mandate_signed_at (rfc3339)
2. What maximum amount, creditor, account and expiry bound the mandate, and did this payment stay inside those bounds?constraint
   Expected answer

   • max_amount (decimal)
   • mandate_creditor_ref (party-ref)
   • mandate_expires_at (rfc3339)
   • within_mandate_bounds (boolean)
3. 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?process
   Expected answer

   • request_to_pay_id (string)
   • request_to_pay_status (enum)
   • resulting_payment_ref (payment-ref)

Artifacts

• ISO 20022 mandate initiation and amendment (pain.009/pain.010) and direct-debit initiation (pain.008)Mandate and direct-debit initiation message instances carrying standing authority separately from each resulting payment.
• ISO 20022 Creditor Payment Activation Request (pain.013) and status report (pain.014)Request-to-pay message instances asking the payer to initiate a credit transfer and reporting the request status.

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.

Questions

1. What is the actual time the order reached the provider, and what is the deemed time of receipt after cut-off rules?temporal
   Expected answer

   • Actual receipt timestamp
   • Deemed receipt timestamp
   • Cut-off rule applied
   • Business day calendar reference
2. Did the parties agree a future execution date or a funds-availability trigger instead of immediate execution?process
   Expected answer

   • Requested execution date
   • Trigger condition
   • Agreement reference
3. Whose business-day calendar governs, and how are divergent calendars across the agent chain reconciled?constraint
   Expected answer

   • Governing calendar owner
   • Closing days list
   • Divergence handling rule
   • Affected hop identifiers

Artifacts

• Order receipt acknowledgementThe 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.

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.

Questions

1. At what precise moment does this payment become irrevocable, and what rule fixes that moment?lifecycle
   Expected answer

   • Irrevocability timestamp
   • Fixing rule reference
   • Rule source (statute, scheme, system)
2. Is a scheme-specific revocation window still open, and who must consent to a late revocation?constraint
   Expected answer

   • Window open (boolean)
   • Window end timestamp
   • Consenting parties required
   • Charge for late revocation
3. Once irrevocable, what recall or return request may be raised and what is the receiver obliged to do?event
   Expected answer

   • Request type
   • Request reference
   • Receiver obligation
   • Response deadline
4. Which fields of an accepted order may be amended without cancelling and reissuing it?constraint
   Expected answer

   • Amendable field list
   • Amendment mechanism
   • Approval requirement
   • Resulting new reference

Artifacts

• Cancellation or recall request recordA 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.

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.

Questions

1. 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?process
   Expected answer

   • payment_order_id (string)
   • issued_at (rfc3339)
   • received_at_psp (rfc3339)
   • initiation_channel (enum)
2. Who was the sender of the order, was a PISP involved, and which payment instrument or procedure was used to initiate it?authority
   Expected answer

   • sender_party_ref (party-ref)
   • pisp_ref (party-ref)
   • payment_instrument_ref (string)
   • receiving_bank_ref (party-ref)
3. 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?temporal
   Expected answer

   • requested_execution_date (date)
   • requested_execution_time (rfc3339)
   • cutoff_applied (string)
   • time_of_receipt (rfc3339)

Artifacts

• UCC § 4A-103 payment-order definition and issuanceStatutory section defining a payment order and fixing when it is issued.
• ISO 20022 pain.001 CustomerCreditTransferInitiation payment information and credit-transfer transaction informationInitiation message instance carrying payment information blocks and one credit-transfer transaction per payment.

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.

Questions

1. Which rail or correspondent chain carried this payment, and what alternatives were reachable?decision
   Expected answer

   • Selected rail identifier
   • Reachable alternatives
   • Selection criteria
   • Selecting participant reference
2. Which settlement method applies between each pair of agents, and where does a cover payment run separately?composition
   Expected answer

   • Settlement method code per hop
   • Cover payment reference
   • Account relationship used
3. Which participant holds credit exposure to which other participant at each stage of the chain?relationship
   Expected answer

   • Exposed participant
   • Counterparty participant
   • Exposure stage
   • Exposure amount
4. Where the payment crosses between rails or message standards, which fields are lost or truncated?interoperability
   Expected answer

   • Boundary crossed
   • Field mapping applied
   • Lost or truncated field list
   • Mitigation applied

Artifacts

• Routing plan and actual route recordA 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.

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.

Questions

1. Did this payment settle individually on a gross basis or as part of a netted position, and in which cycle?process
   Expected answer

   • Settlement mode code
   • Cycle identifier
   • Net position reference
   • Cycle close timestamp
2. In which settlement asset was the obligation discharged between participants, and who issues that asset?classification
   Expected answer

   • Settlement asset type
   • Issuer reference
   • Claim characteristics
   • Credit risk assessment
3. Was the payment queued or delayed for liquidity, and which liquidity-saving mechanism resolved it?measurement
   Expected answer

   • Queued flag
   • Queue entry timestamp
   • Queue release timestamp
   • Mechanism applied
   • Priority assigned
4. If a participant defaults mid-cycle, what happens to this payment under the system's default rules?exception
   Expected answer

   • Default rule reference
   • Unwinding permitted (boolean)
   • Payment disposition on default
   • Loss allocation basis

Artifacts

• Clearing cycle settlement instructionThe 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.

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.

Questions

1. What execution deadline applied to this payment, and was it met measured from the deemed time of receipt?requirement
   Expected answer

   • Applicable deadline rule
   • Deadline timestamp
   • Actual arrival timestamp
   • Compliance outcome
2. How do the settlement timestamp, the credit value date and the time funds became available to the payee differ?temporal
   Expected answer

   • Settlement timestamp
   • Debit value date
   • Credit value date
   • Funds availability timestamp
3. How much value-dating float arose between debit and credit, and to whom did the benefit accrue?measurement
   Expected answer

   • Float duration
   • Float value
   • Benefiting party reference
   • Permitted under rule (boolean)
4. How is a settlement record confirmed as authoritative rather than provisional or inferred?quality
   Expected answer

   • Confirmation source
   • Confirmation message reference
   • Provisional flag
   • Reconciliation status

Artifacts

• Settlement confirmation recordThe 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.

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.

Questions

1. At what moment did this payment become final, and which system rule or legal rule fixes that moment?state
   Expected answer

   • Finality timestamp
   • Fixing rule reference
   • Rule layer (system rules, statute, case law)
   • Asserting participant reference
2. Where the operational finality point and the legal moment of payment differ, which governs for which purpose?authority
   Expected answer

   • Operational finality timestamp
   • Legal payment moment
   • Divergence reason
   • Governing rule per purpose
3. Do any of the recognised exceptions prevent the underlying obligation from being discharged by this payment?exception
   Expected answer

   • Exception invoked
   • Exception basis
   • Beneficiary refusal record
   • Subrogation outcome
4. After finality, on what basis could funds still be recovered, and is that a reversal or a new payment?event
   Expected answer

   • Recovery basis
   • Mechanism used
   • New payment reference
   • Original payment left intact (boolean)

Artifacts

• Finality attestationA 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.

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.

Questions

1. Is this payment's finality conditioned on another payment, a securities delivery or another obligation, and which record is the linked leg?composition
   Expected answer

   • linked_obligation_type (enum)
   • linked_payment_ref (payment-ref)
   • linked_securities_instruction_ref (string)
   • pvp_or_dvp_model (enum)
2. What rule makes settlement of this leg occur only if the other leg settles, and is principal risk thereby eliminated?constraint
   Expected answer

   • conditionality_rule (string)
   • principal_risk_eliminated (boolean)
3. If the linked leg fails, is this payment rejected, held, unwound or settled independently?lifecycle
   Expected answer

   • linked_failure_action (enum)
   • unwind_indicator (boolean)

Artifacts

• PFMI Principle 12 exchange-of-value settlement systems and CPMI glossary DvP/PvP finality languagePrinciple and glossary language conditioning final settlement of one obligation on final settlement of the linked obligation.

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.

Questions

1. 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?temporal
   Expected answer

   • time_of_receipt (rfc3339)
   • execution_date (date)
   • value_date (date)
   • funds_available_at (rfc3339)
   • settled_at (rfc3339)
   • observed_at (rfc3339)
2. 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?measurement
   Expected answer

   • sla_seconds (integer)
   • sla_met (boolean)
   • availability_lag_seconds (integer)
   • confirmation_lag_seconds (integer)
3. What settlement lag elapsed from system acceptance to final settlement, and did the payment miss value date?process
   Expected answer

   • accepted_for_settlement_at (rfc3339)
   • settlement_lag_seconds (integer)
   • missed_value_date (boolean)

Artifacts

• Regulation 260/2012 as amended — instant credit-transfer time of receipt, 10-second availability and confirmationLegislative clauses fixing time of receipt and the ten-second availability and confirmation duties for instant credit transfers.

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.

Questions

1. Which participant reported this status, about which leg, and as at what moment?state
   Expected answer

   • Reporting participant reference
   • Leg identifier
   • Status code
   • Status as-at timestamp
2. Which code set does this status reason belong to, and what is its meaning in that set's version?classification
   Expected answer

   • Code set identifier
   • Code set version
   • Reason code
   • Decoded meaning
3. When two participants report conflicting statuses for the same payment, which is treated as authoritative?quality
   Expected answer

   • Conflicting status pair
   • Precedence rule applied
   • Resolved status
   • Resolution timestamp
4. What information is lost when a scheme reason code is mapped to an internal or customer-facing status?interoperability
   Expected answer

   • Source code
   • Target status
   • Mapping table reference
   • Lost distinctions

Artifacts

• Payment status reportA 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.

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.

Questions

1. What is the ordered sequence of lifecycle events for this payment, and how is ordering established across participants?lifecycle
   Expected answer

   • Event type sequence
   • Ordering basis
   • Sequence number
   • Cross-participant reconciliation note
2. For each event, when did it occur on the rail and when was it observed or ingested here?temporal
   Expected answer

   • Event timestamp
   • Observation timestamp
   • Latency
   • Time source
3. Which state transitions are permitted from the current state, and which observed transition was invalid?event
   Expected answer

   • Current state
   • Permitted next states
   • Observed transition
   • Validity outcome
4. What is the source and trust level of each recorded event, and was any event inferred rather than reported?provenance
   Expected answer

   • Event source participant
   • Source channel
   • Inferred flag
   • Inference basis

Artifacts

• Payment lifecycle event logAn 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.

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.

Questions

1. Which mechanism was used to move value back, and did it create a new payment or unwind the original?process
   Expected answer

   • Mechanism code
   • New payment reference
   • Original payment left final (boolean)
   • Scheme rule reference
2. What reason was cited for the return or recall, and was it raised within the scheme's permitted window?temporal
   Expected answer

   • Reason code
   • Window duration
   • Raised timestamp
   • Within window (boolean)
3. Where a recall request was refused, on what ground, and what remedy remains to the requester?exception
   Expected answer

   • Refusal ground code
   • Refusing participant
   • Remaining remedies
   • Escalation path
4. How is a returned payment linked back to the original so that neither is double-counted?relationship
   Expected answer

   • Original payment reference
   • Return payment reference
   • Linkage type
   • Net economic effect

Artifacts

• Return or recall case recordA 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.

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.

Questions

1. Which event started the dispute or claim clock, and when does each applicable deadline expire?temporal
   Expected answer

   • Clock start event
   • Clock start timestamp
   • Deadline list with expiry timestamps
   • Governing rule reference
2. Was provisional credit required, in what amount, and was it granted within the prescribed period?requirement
   Expected answer

   • Provisional credit required (boolean)
   • Credit amount
   • Credit granted timestamp
   • Compliance outcome
3. Who bears the loss for this disputed payment, and which factor determined the allocation?ownership
   Expected answer

   • Liability holder reference
   • Liability amount
   • Determining factor
   • Liability cap applied
4. What evidence was gathered and disclosed to the claimant, and in what readable form?evidence
   Expected answer

   • Evidence item list
   • Disclosure timestamp
   • Format converted to readable form (boolean)
   • Withheld items and basis

Artifacts

• Dispute case fileThe 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.

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.

Questions

1. Which obligations does this payment discharge, in what allocated amounts, and who decided the allocation?relationship
   Expected answer

   • Obligation reference list
   • Allocated amount per obligation
   • Allocating party reference
   • Allocation timestamp
2. What residual remains unallocated or unpaid after this payment, and how is it carried forward?measurement
   Expected answer

   • Unallocated payment amount
   • Residual obligation balance
   • Carry-forward treatment
3. Under what conditions could this discharge be undone, and what would then revive the obligation?constraint
   Expected answer

   • Reversal condition list
   • Revival mechanism
   • Notification duty
   • Governing rule reference

Artifacts

• Payment allocation adviceA 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.

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.

Questions

1. What purpose and category purpose are declared for this payment, and who assigned them?classification
   Expected answer

   • Purpose code
   • Category purpose code
   • Code set version
   • Assigning party reference
2. Does remittance information travel inside the payment or as a separate advice, and how are the two bound?composition
   Expected answer

   • Carriage mode
   • Remittance location reference
   • Binding identifier
   • Delivery confirmation
3. Where remittance data exceeds what a rail can carry, what is truncated and how is the loss signalled?interoperability
   Expected answer

   • Rail capacity limit
   • Truncated content
   • Truncation signal
   • Fallback channel used
4. Which intermediaries can read the remittance content, and does it disclose commercially sensitive detail?privacy
   Expected answer

   • Reading participant list
   • Sensitivity classification
   • Redaction option available (boolean)
   • Contractual confidentiality basis

Artifacts

• Standalone remittance adviceA 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.

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.

Questions

1. Which party issued each confirmation, advice or statement, and what does that party actually attest to?provenance
   Expected answer

   • Issuing party reference
   • Document type
   • Scope of attestation
   • Issue timestamp
2. How does a statement entry bind back to the payment, and what happens when the binding reference is absent?evidence
   Expected answer

   • Entry reference
   • Binding key used
   • Unbound entry handling
   • Manual match indicator
3. Is the statement series complete and gap-free, and how are missing or duplicated statements detected?quality
   Expected answer

   • Sequence numbers received
   • Gap list
   • Duplicate list
   • Detection method
4. Which parties may obtain a copy of the payment evidence, and on what lawful basis?access
   Expected answer

   • Requesting party role
   • Disclosure basis
   • Redactions applied
   • Disclosure record reference

Artifacts

• Payment confirmation and account statementThe 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.

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.

Questions

1. What is the current three-way match state between instruction, settlement confirmation and statement entry?validation
   Expected answer

   • Match state code
   • Matched references
   • Unmatched side
   • Match timestamp
2. Which facts does this model hand to the accounting model, and which decisions does it deliberately not make?process
   Expected answer

   • Handed fact set
   • Excluded decision list
   • Handoff interface reference
   • Posting reference returned
3. How long has each reconciliation break been open, and what is the escalation threshold?measurement
   Expected answer

   • Break reference
   • Break age
   • Escalation threshold
   • Owning role
4. If a payment fact is later corrected, how is the previously produced posting handled?quality
   Expected answer

   • Correction type
   • Original posting reference
   • Correction mechanism
   • Period impact

Artifacts

• Reconciliation result setThe 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.

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.

Questions

1. Which regulatory regimes apply to this payment, and which jurisdictions triggered each of them?authority
   Expected answer

   • Regime reference list
   • Triggering jurisdiction per regime
   • Determination basis
   • Determination timestamp
2. Which jurisdictions did the payment touch through its parties, agents and settlement location?spatial
   Expected answer

   • Party jurisdictions
   • Agent jurisdictions
   • Settlement location
   • Data residency implications
3. Which originator and beneficiary information had to accompany the transfer, and was it complete on arrival?requirement
   Expected answer

   • Required data set
   • Transmitted data set
   • Missing elements
   • Receiving institution action
4. When a regime's application date falls between instruction and settlement, which rules govern this payment?temporal
   Expected answer

   • Regime application date
   • Instruction timestamp
   • Settlement timestamp
   • Governing rule determination

Artifacts

• Regulatory determination recordA 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.

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.

Questions

1. Who may read a payment record by default, and which additional roles require an explicit grant?access
   Expected answer

   • Default reader roles
   • Grant-required roles
   • Granting steward
   • Grant scope and expiry
2. What retention basis and period applies to each class of element, and which elements must be purged earliest?retention
   Expected answer

   • Element class
   • Retention basis
   • Retention period
   • Earliest purge trigger
3. How is a deletion obligation satisfied against an append-only settlement and event record that must remain intact?privacy
   Expected answer

   • Deletion technique
   • Elements redacted
   • Elements retained
   • Integrity preservation method
4. Which elements are prohibited from storage after authorisation, and how is that prohibition enforced and tested?security
   Expected answer

   • Prohibited element list
   • Enforcement control
   • Testing method
   • Last verification timestamp

Artifacts

• Retention and access policy bindingThe 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.

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.

Questions

1. 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?constraint
   Expected answer

   • originator_name (string)
   • originator_account_id (string)
   • beneficiary_name (string)
   • beneficiary_account_id (string)
   • travel_rule_complete (boolean)
   • verification_performed (boolean)
2. What sanctions or restrictive-measures screening status applies, was the transfer rejected, suspended or frozen, and which hit reference supports that decision?exception
   Expected answer

   • screening_status (enum)
   • screening_list_hit_ref (string)
   • funds_frozen_indicator (boolean)
   • suspend_or_reject_reason (string)
3. 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?spatial
   Expected answer

   • originator_address (object)
   • beneficiary_country (iso-3166)
   • chain_jurisdictions (iso-3166[])
   • full_payload_required (boolean)

Artifacts

• FATF Recommendation 16 payment-transparency update (June 2025) originator and beneficiary information requirementsRevised recommendation text setting required originator and beneficiary information and chain responsibilities.
• EU transfer-of-funds accompanying information and missing-data handlingRules requiring payer and payee information to accompany transfers and requiring the payee's PSP to detect missing data.