Funtional overview
The Zelle implementation built from the payment exception recovery case model workflow consists of claim and transaction exception case types. The claim case is used for account and transaction selection and to capture basic information about the disputed transaction. The Zelle case type is created and treated as either a potential fraud or scam or a non-fraud exception based on the supplemental information collected at the claim level. The Zelle case type manages the exception processing from initiation to resolution.
The Claim case type is used for the following actions:
- Select account: The search is initiated using demand deposit account number.
- Select transaction: The list of transactions associated with the account are displayed in the transaction grid with Zelle in the Description column as radio buttons. The relevant disputed transaction is selected for further exception processing.
- Collect supplemental information: The response to the question about customer participation determines the possible fraudulent activity. If the customer is a victim of fraud or a scam, then the claim is considered fraud, else the claim is considered as non-fraud. The customer service representative is guided to collect information based on the response. As Zelle does not publish any authorized questionnaire, a bank may add or modify questions based on bank policy.
The Zelle case type is used for the following actions:
Evaluate for possible duplicate cases
The application looks for duplicate cases in the application to ensure that the exception has not been previously processed. If any case is identified as a potential duplicate, the user may resolve the current case as a duplicate with the status as Resolved-Duplicate or choose to ignore the duplicate case and continue with the dispute.
Low value write-off
The application evaluates the transaction against the configured threshold and condition and writes off a transaction if the disputed amount is less than the configuration.
Customer interview
The customer interview is used to select the reason and sub-reason for the disputed transaction and answer the questionnaires specific to the reason the customer is filing. The DisputeReasonMatrix data type provides the information about the dispute reason for a payment network. It also allows clients to add a new dispute reason or remove a dispute reason. This data type is a configuration point for the client to add, update, or remove exception reasons that may apply to a specific payment network.
Exception validation
Dispute validations are used to validate the transaction against the payment type mandated validation and conditions applicable for the selected exception reason. The validations data type provides the information about the validations available for a particular exception. If any validations fail or have an inconclusive status, the case lands on the Dispute validation screen for users to either proceed with liability processing (courtesy write-off the case or mark it as sender-liable) or continue to raise the dispute regardless of the failed validations. Users can review the validations in the footer section with the statuses against each validation rule.
As most of the newer payment methods have not published set validations similar to Visa or Mastercard, the issuer may either bypass this step in the Payment Exception Recovery case or build out validations based on bank policy and other factors.
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 the case to a specific network based on their requirements.
Accounting
Accounting generates standard accounting entries for each action such as Write-off and Cardholder liable. Clients can update the entries with their chart of accounts and can configure them for policies or processing requirements.
Payer/Payee communication
The application generates an automatic correspondence acknowledging the receipt of exception claim for processing to the payor/sender of funds. Clients can configure the correspondence according to their needs and approved bank verbiage. It also generates automatic correspondence to be sent to the customer for contacting or reversal of funds as determined necessary.Configurations
The following configurations are available for Payment Exception Recovery under the Configuration set Payment Exception Configurations which are being reused for Zelle.
- Duplicate Search - Boolean data type with default value true
- Enable Accounting - Boolean data type with default value true
- Enable External Accounting - Boolean data type with default value true
Extensions
The Zelle case flow contains many extension points for clients to extend the functionalities specific to the Issuer’s requirements. For more information on extension points, refer the implementation guide.
Previous topic Zelle Payments Exception Process Overview Next topic Future development scope