Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Funtional overview

Updated on June 22, 2022

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.

Pega Smart Dispute for Issuers

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 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.


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


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.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us