Question / Problem:
How to handle out of sequence transactions in Testkey?
Answer / Solution:
Typically you would expect transactions to arrive in sequential order. Occasionally it is possible certain transactions may go missing or arrive at a later date. Out of Sequence transactions are not unusual. Banks exchange many transactions in a day, some of which are not sent in encoding order or decoded in order of receipt. As a result messages become out of sequence.
The Test key application handles out of sequence decodes in the following ways:
i. Out of sequence decodes which are within tolerance are accepted into the cycle
In this case, the current cycle remains uninterrupted.
ii. Out of sequence decodes which are outside of tolerance are failed to the Repair queue
If the missing transaction arrives out of tolerance, there is a manual intervention required. The user gets the option to do an “out of sequence decode”. The steps to handle out of sequence decodes that are outside the tolerance range are listed in the section below.
Out of sequence decode - Recovery steps
If a transaction has not arrived it will appear in the UI with a Missing status
This transaction could arrive from the counterparty at a later stage. In which case if it is also out of tolerance then this event is known as an “Out of Sequence” event which will trigger a “Decode - Out of Sequence” Dialogue box to appear automatically.
Note: there is a default tolerance range of 0-99 for out of sequence decodes
The dialog box will present 3 Actions / Alternatives as summarized below.
Accept (into cycle)
Accept the transaction, this creates a subset of missing sequences between this and the last tested transaction
Fail (to summary)
Fail the transaction, ,marking it as failed in the Transaction summary
Fail (send to repair)
Fail the transaction and send it to the repair desk for another user to process
Note: this option must be selected if you want to access and modify the failed transaction using the Repair menu
If an out of sequence transaction is received, it is recommended it is dealt with in the following manner –
1. Current cycle should not be disturbed
2. The out of sequence item should ideally be dealt with from the Repair queue
For the recommended approach, Option 3 (Fail – sent to repair) should be selected on the incoming transaction that is out of sequence. This should update the Status of the message to “Out of Sequence” on the Transaction queue and will also make it appear in the Repair queue.
A supervisor/authorizer user can then examine the transaction on the Repair queue and perform the necessary corrective actions on this transactions (as described in the next section).
Steps to Decode from Repair Queue
1. Click Out of Sequence Decode on the Repair Menu
2. Open the message you want to examine by double clicking it
3. From here below two options are available:
a. Fail (to summary) the out of sequence decode. In this case, the decoded item will not occupy a cycle position.
b. Accept (into cycle) the out of sequence decode. The software will check if the active sequence number in the running cycle for the counterparty has gone outside tolerance then the user is informed and has the option to abandon or accept the out of sequence transaction.
If the user accepts the transaction then in the view between the accepted and the last transaction will be back-filled with the remaining sequence numbers. These back-filled items will appear with a “Missing” status. It must be noted these are NOT missing transactions. These are padded transactions around the accepted sequence number.
4. If the out of sequence transaction is decoded into a running cycle, the user will need to manually reset the active sequence position for the incoming transactions for the counterparty. The number should be reset to the next expected sequence number in order to resume the current cycle.
Author: Shivani Gupta