Validation for Returns and Reversals in FTM CPS

Bank of Nova Scotia (aka Scotia Bank) in Canada is implementing IBM FTM CPS to support electronic payments processing compliant with Payments Canada Standard 005.

According to the standard (Standard 005 - link), **certain fields marked with * or ** are mandatory and must be validated during the processing of Return and Reversal transactions to ensure proper correlation with the original (forward) payment.

However, during implementation testing, it was found that the current product version does not validate many of these mandatory fields out-of-the-box.

For Return Transactions, the following fields are NOT being validated:

Originating Direct Clearer's User ID

Originator's Cross Reference Number

Stored Transaction Type

Institutional Identification Number

For Reversal Transactions, the following fields are NOT being validated:

Institutional Identification Number

Stored Transaction Type

Originator's Short Name

Payee Name

Originator's Long Name

Originating Direct Clearer User ID

Originator's Cross Reference Number

Originator's Sundry Information

Originator-Direct Clearer Settlement Code

Invalid Data Element Number

For Incoming rejected transactions with Reason Code 900

FTM CPS must support a simplified correlation and validation mechanism. Only the following fields should be validated and used for correlating the rejected transaction to the original forward transaction:

Amount
Date Funds to Be Available
Originating Direct Clearer’s User ID
Originator’s Cross Reference Number
Stored Transaction Type (must match the original transaction’s transaction type)

All other CPA005 mandatory field validations should be bypassed for 900 Rejects.
If any of the above validations fail, CPS should reject the 900 transaction and must not update the status of the original forward transaction.
This behaviour should be configurable and apply only to Reason Code 900, without impacting other Return/Reversal processing.

Ideally CPS should validate all the fields and functionality as per CPA standards and customers should have the ability to by-pass if they feel like specific validation is not required for them.

Proposed Enhancement to support these validation at product level and enhance process logic to prevent updating the original transaction’s status if any of the mandatory validations fail.