Uncertain payment outcomes and technology risk

Monetary Authority of Singapore · Consultation response ·

Examines duplicate transactions caused by retries after an uncertain payment outcome. Recommends supervisory examples covering risk assessments, warning indicators and incident records, so institutions can trace one instruction across systems, test lost acknowledgements and concurrent retries, and reconcile unresolved outcomes.

Read the response (PDF, 3 pages)

The document

Title
Response to MAS Consultation P012-2026: uncertain-outcome retry in technology risk management
Consultation
Proposed Amendments to Notices on Technology Risk Management, P012-2026
Questions answered
Questions 2 and 7
Capacity
Personal capacity
Submitted
Length
3 pages
Confidentiality
None. “I am fine with publishing my whole submission along with my identity.”

The case it puts

The example is an uncertain-outcome retry. A transaction may have completed, its definitive acknowledgement may be lost, and an automatic retry may produce an unpermitted repeat. No component need be defective or malicious: each attempt can look locally valid while different identifiers obscure that both arose from one business instruction.

The response suggests MAS use it as a non-exhaustive example in guidance for relevant critical transaction systems: “Where the operation or disruption of a critical system can cause or conceal a material external transaction, the FI should assess whether an unknown outcome followed by a retry can produce a transaction inconsistent with the recorded expected outcome, including across material dependencies.”

That is an illustrative technical control, not a proposed MAS term. It does not by itself prove customer intent, delegated or legal authority, settlement finality, redress or liability.

What it recommends

  1. Show the binding in the risk register. Where the risk is material, the register should show how one business instruction is identified or mapped across retries and material boundaries, including where the same request arrives under a fresh identifier or one intended transaction fans out into child effects.
  2. Name the test. A useful test loses the acknowledgement before or after commitment, retries concurrently or under a fresh identifier, and returns partial results late or out of order. Repeated submissions should select the same application result, while each transaction-creating component separately prevents an unintended repeat.
  3. Publish key risk indicator examples without fixing thresholds. Aged in-doubt count and value, outcomes inconsistent with the recorded expectation, unresolved instruction-to-transaction breaks, the separately reported coverage of direct correlation and tested compensating controls, availability of the identity record, and reconciliation time. Each institution can set thresholds according to materiality, the delay before reliable evidence arrives and customer impact.
  4. Make the incident record reconstructable. The incident owner should be able to reconstruct one business instruction across its attempts, identifier mappings and child effects, preserving the expected outcome, any recorded authorisation, reliable timestamps, attempts and acknowledgements, observable transaction references, the outcome and any correction.

Unresolved items enter reconciliation; they are not assumed to have failed. A timeout is not evidence that an instruction failed, and a successful retry is not evidence that the first attempt failed.

Sources