Payment Exception Recovery – Model Workflow

Claim case type is used for the below actions:

• Select account: The search is initiated through an account or card number.
• Select transaction: List of transactions associated with the account or card are displayed in the transaction grid as radio buttons. The relevant exception transaction is selected to proceed further in the Payment Exception Recovery processing.
• Collect supplemental information: The response to the question about customer participation determines the possible fraudulent activity. If the customer participated in the transaction(s) within the claim it is considered as non-fraud. If the customer did not participate in the transaction(s) in the claim, the claim is considered fraud. Basic fraud and non-fraud questionnaires are displayed to the customer service representative based on the response.

Transaction case type is used for below actions:

• Evaluate duplicate: The application searches for duplicate cases to ensure that the dispute is not processed more than once by the client representatives. If any case is identified as a potential duplicate, the user can close the current case as a duplicate with status as Resolved-Duplicate or choose to ignore the duplicate case and continue with the dispute.
• Low value write-off: The application evaluates the claim and the transactions against the business defined threshold for low dollar write-off. In the case of the disputed item each transaction is reviewed for write-off. If the claim is determined to be fraud the claim is reviewed for low dollar write-off to maintain the full details of the fraudulent transactions associated with the claim.
• Customer interview: This is used to select the reason and sub reason for the disputed transaction and answer the questionnaires specific to the reason for the exception and questions necessary to complete the case details. . The DisputeReasonMatrix data type provides the information about the exception reason for a payment network. This data type is a configuration point for the client to add, update, or remove exception reasons for a specific payment network.
• Exception validation: This is used to validate the transaction against the payment type mandated validation and conditions applicable for the selected exception reason code. The validations data type provides the information about the exception validations available for a specific exception reason. Clients can also add new exception validations or remove exception validations. If any validations fail or have an inconclusive status, then the case lands on the exception validation screen for users to either proceed with liability processing (write-off the case or mark it as customer liable) or continue to raise the exception regardless of the failed validations. Users can review the validations in the footer section with the statuses against each validation rule.
• Evaluate provisional credit: This is an option to provide Provisional Credit (PC) for the exception transaction based on the configuration in the decision table. Provisional credit is an interim credit that the bank provides to the customer for the exception amount while the case is under investigation. The system uses a configurable decision table to evaluate the eligibility for PC based on exception type, product type, transaction type, reason code and transaction amount.
• Submit to counter party: This process is a placeholder step with pre-processing or post-processing extension points for the clients to configure the exception and submit to the counterparty based on their processing requirements.
• Accounting: Accounting generates standard accounting entries for each action such as provisional credit, write-off, and cardholder liable. Clients can update the entries with their chart of accounts and can customize them for policies or processing requirements that are specific to their institution or the payment type.
• Customer communication: Customer Communication generates an automatic correspondence acknowledging the receipt of the exception claim for processing to the payor. Clients can configure the correspondence according to their needs.
• Configurations: There are currently three configurations available for Payment Exception Recovery under the Configuration set “Payment Exception Configurations”.
  • Duplicate Search – Confirming if identical or similar claims have been entered previously to avoid duplicate cases in process.
  • Enable Accounting – Part of the claim and transaction cases resolution includes accounting messages for the required debits and credits that are delivered to the client internal systems based on configuration.
  • Enable External Accounting – If there is a requirement for accounting messages to be sent to an external system or 3rd party chart of accounts this configuration is possible during deployment.
• Extensions: The Payment Exception Recovery model workflow contains extension points for clients to extend the functionalities specific to the Issuer’s requirements. For more information on extension points, refer the implementation guide.

Resources

• Overview Guide
• Installation Guide
• Implementation Guide