An investor submits a transaction, sees an error and tries again. Behind the interface, the first instruction may still be processing. A future asset-servicing system needs a way to recognise that situation and determine the actual state before accepting another action. The operating decision is how to make interruption recoverable without creating duplicate obligations or misleading confirmations.
Give the instruction a durable identity
The accepted request should have an identifier connecting its approvals, external submissions and later responses. An interface refresh should not erase that history. CPSS-IOSCO's operational-risk principles provide context for dependable records and procedures. A hypothetical connection timeout can mean that the service did not receive an answer, rather than that nothing happened. The workflow should preserve the unresolved state and obtain evidence from the relevant system. Owners need enough information to distinguish a failed submission from an unknown outcome. Investors should receive an explanation that accurately reflects that distinction instead of being encouraged to repeat the transaction without qualification.
Define what a retry may do
The system should determine whether a repeated request continues an existing instruction, replaces it under controlled conditions or creates a separate transaction. The choice needs to be explicit in the design and testing. BIS's tokenisation analysis supports examining the relationships between technical records and the surrounding arrangements. A hypothetical batch process should not interpret the same instruction twice merely because a provider resends a message. Technical teams need controls appropriate to their architecture, while operations need a record showing how duplicates are recognised and what action is taken when two similar requests are actually intended as different transactions by the investor.
Reconcile external acknowledgements
Payment providers, registries and ledger systems may report at different times. The servicing team should identify which messages establish receipt, acceptance, execution and final completion. Missing or conflicting responses need an exception route. A hypothetical transfer marked failed internally but completed externally requires investigation before any corrective movement is authorised. Owners should avoid manual adjustments that make one screen agree while leaving the authoritative records inconsistent. Support staff need a clear escalation path and enough access to explain the case without taking technical actions outside their authority simply to resolve an investor complaint quickly or improve a queue statistic.
Test recovery under realistic interruption
Commissioning should include duplicated messages, delayed responses and restarts at meaningful points in the workflow. The resulting record should demonstrate that positions and cash remain coherent under the agreed handling rules. Investors gain confidence from accurate communication and a traceable outcome, not an unconditional claim that software never fails. Owners should review repeated failures for underlying capacity, provider or design issues. A robust service can describe the instruction's history and its final disposition. That makes recovery part of normal operating design, allowing an exception to be investigated and resolved without losing the relationship between the investor's original intention and the movements ultimately recorded.
