pega smart dispute for issuers...application overview application overview pega smart dispute for...

Pega Smart Dispute for IssuersImplementation Guide

7.4

©2018 Pegasystems Inc., Cambridge, MA. All rights reserved.

Trademarks

For Pegasystems Inc. trademarks and registered trademarks, all rights reserved. All other trademarks orservice marks are property of their respective holders.

For information about the third-party software that is delivered with the product, refer to the third-partylicense file on your installation media that is specific to your release.

Notices

This publication describes and/or represents products and services of Pegasystems Inc. It may containtrade secrets and proprietary information that are protected by various federal, state, and internationallaws, and distributed under licenses restricting their use, copying, modification, distribution, or transmittalin any form without prior written authorization of Pegasystems Inc.

This publication is current as of the date of publication only. Changes to the publication may bemade from time to time at the discretion of Pegasystems Inc. This publication remains the propertyof Pegasystems Inc. and must be returned to it upon request. This publication does not imply anycommitment to offer or deliver the products or services described herein.

This publication may include references to Pegasystems Inc. product features that have not been licensedby you or your company. If you have questions about whether a particular capability is included in yourinstallation, please consult your Pegasystems Inc. services consultant.

Although Pegasystems Inc. strives for accuracy in its publications, any publication may containinaccuracies or typographical errors, as well as technical inaccuracies. Pegasystems Inc. shall not be liablefor technical or editorial errors or omissions contained herein. Pegasystems Inc. may make improvementsand/or changes to the publication at any time without notice.

Any references in this publication to non-Pegasystems websites are provided for convenience only anddo not serve as an endorsement of these websites. The materials at these websites are not part of thematerial for Pegasystems products, and use of those websites is at your own risk.

Information concerning non-Pegasystems products was obtained from the suppliers of those products,their publications, or other publicly available sources. Address questions about non-Pegasystemsproducts to the suppliers of those products.

This publication may contain examples used in daily business operations that include the names ofpeople, companies, products, and other third-party publications. Such examples are fictitious and anysimilarity to the names or other data used by an actual business enterprise or individual is coincidental.

This document is the property of:

Pegasystems Inc.One Rogers StreetCambridge, MA 02142-1209, USAPhone: 617-374-9600 Fax: 617-374-9620

www.pega.com

Document: Pega Smart Dispute for Issuers 7.4 Implementation Guide

Feedback

If you have comments for how we can improve our materials, send an email to [email protected].

http://www.pega.com/

mailto:[email protected]?subject=Documentation%20feedback

Contents

Contents

Application overview.................................................................................................................................................................................5Implementation delivery methodology....................................................................................................................................................5

Initiation stage...............................................................................................................................................................................5Delivery stage................................................................................................................................................................................ 6

Initiation stage...........................................................................................................................................................................................8Creating your application.......................................................................................................................................................................... 8Customer sample data...............................................................................................................................................................................9Enabling operator accounts...................................................................................................................................................................... 9Generating specification documents........................................................................................................................................................9

Generating the Application profile...........................................................................................................................................10Generating the Application document.................................................................................................................................... 10Generating the Specification document..................................................................................................................................10

Delivery stage...........................................................................................................................................................................................11Defining requirements............................................................................................................................................................................. 11

Mapping your application data................................................................................................................................................ 11Defining integration....................................................................................................................................................................12Defining the case type modifications and attributes............................................................................................................ 12Application data model..............................................................................................................................................................13Defining the security model and organization structure.....................................................................................................14Customizing the user experience.............................................................................................................................................16Defining reporting requirements..............................................................................................................................................17Defining accounting step rules.................................................................................................................................................17

Building features.......................................................................................................................................................................................17Modifying the class structure................................................................................................................................................... 18Implementing the security model............................................................................................................................................18Modifying the user interface.....................................................................................................................................................18Reports......................................................................................................................................................................................... 20Configuring the dispute main flow.......................................................................................................................................... 20Implementing Visa Claims Resolution (VCR)...........................................................................................................................29Implementing MasterCom Claims Manager (MCOM)............................................................................................................35Configuring application fraud properties................................................................................................................................41Setting up correspondence verification.................................................................................................................................. 44Modifying automatic correspondence.....................................................................................................................................44Modifying automatic correspondence generation.................................................................................................................44Modifying the OnUs decision map.......................................................................................................................................... 46Modifying dispute qualification scripts....................................................................................................................................47Setting up duplicate scoring rules........................................................................................................................................... 47Modifying multiple partial dispute values...............................................................................................................................48Configuring reassertion values................................................................................................................................................. 48Defining new bank identification numbers............................................................................................................................ 49Configuring approval flows....................................................................................................................................................... 49Working with accounting functions..........................................................................................................................................49Integrating data...........................................................................................................................................................................56Configuring integration components.......................................................................................................................................57

Testing a new application........................................................................................................................................................................63

Pega Smart Dispute for Issuers Implementation Guide | August 03, 2018 | iii

Testing your application in the Build environment............................................................................................................... 64Testing in the Test or Production environments....................................................................................................................64Testing in the UAT environment...............................................................................................................................................65

Packaging a new application...................................................................................................................................................................65Merging application changes.................................................................................................................................................... 65Packaging an application for migration.................................................................................................................................. 66Importing the packaged application........................................................................................................................................66

Production maintenance and monitoring............................................................................................................................................67Business rule maintenance in the Production environment..............................................................................................................67Application health monitoring................................................................................................................................................................ 67Identifying and reporting issues.............................................................................................................................................................67

Application overview

Application overviewPega Smart Dispute for Issuers (FFS) is a foundational application that provides common, reusablecomponents on which other financial service applications, can be built.

The application uses a base data model that represents commonly used financial services objects, suchas people, organizations, accounts, and transactions. You can model complex party-to-party relationshipsbetween organizations and individuals by using cross reference.

The application contains a set of sub-ledger accounting and adjustments facilities. It supports end-to-end management of financial transactions, including suspense and adjustment accounting, write-offmanagement, accounting cut-off management, multi-level verification, and correspondence generation.

The application provides requirement-gathering capabilities that are used to help organizations managemulti-stage, complex document and requirement collection processes.

The application comes with prebuilt integrations for Equifax and Markit services. They are built into theapplication layer and can be used with Financial Services applications.

Pega Smart Dispute for Issuers contains the optional Product Designer for Financial Services application. Iflicensed, it can be installed with onboarding, marketing, and sales applications. Details for this applicationcan be found on the PDN.

• Implementation delivery methodology

Implementation delivery methodologyIn most cases, use a scrum-based, Agile delivery model for a Pega application implementation. In the rarecases where a waterfall-based implementation methodology is better suited, use Pega’s Iterative Waterfallapproach. These two implementation methodologies help break down the work into manageablecomponents that you can deliver to production faster. The Pega delivery approach has the followingprimary stages:

• Initiation stage

• Delivery stage

Initiation stageIn the Initiation stage, the implementation teams build the foundation or baseline of the application andprepare for the work that is necessary to configure the first production release and subsequent extendedproduction releases. Keep in mind that the first production release is the minimal required scope to golive into production. Other capabilities can be added as part of the extended production releases. Buildinga strong foundation to support expansion and reuse is key to the success of an implementation.

The Initiation stage is further organized into the following sub-stages:

Plan

Align the vision and roadmap to establish the foundation for the implementation. The Plan sub-stageincludes the following tasks:

• Defining the production release milestone

• Refining scope alignment

Pega Smart Dispute for Issuers Implementation Guide | August 03, 2018 | 5

https://pdn.pega.com/products/pega-foundation-financial-services


Set up

Validate and review the Pega-provided features and capabilities to see if they meet your requirements andexpectations. This sub-stage includes the following tasks:

• Establishing environments and processes

• Reviewing application feature descriptions (in Designer Studio, click Application > Overview)

• Reviewing Application Guides for first production release setup information (in App Studio, click Toggledesign mode in the upper-right corner to see the Application Guides steps)

• Creating the baseline application

• Loading customer data

• Demonstrating the baseline application

• Reviewing artifacts from the solution assessment

• Reviewing business needs and outcomes

Prepare

Prepare for the delivery of Pega Smart Dispute for Issuers by completing the following tasks:

• Confirming resources

• Enabling team members

• Establishing governance

At the conclusion of the Initiation stage, the scope of the work for the first production release is clearlydefined. For Scrum, the scope of the work is represented in an initial backlog. For Iterative Waterfall, aspecification list and schedule are prepared and finalized.

Delivery stageThe Delivery stage is dependent on the methodology selected (Scrum or Iterative Waterfall). Duringthis stage, the delivery team designs, builds, configures, and tests the application by using the selectedimplementation methodology. The goal is to accomplish the tasks that are described in this documentby organizing the Application Feature backlog so that the delivery team can configure the applicationincrementally with the result being a fully tested and performance-tuned application in production.

The Delivery stage is organized into the first production release and the extended production releasetypes.

First production release

This release includes only the essential features that are defined during the solution proposal stage andare required for the first release into production. The first production release should be implemented in90 days or less, depending on the scope of the essential features. This release type includes the followingfeatures:

• Core Pega-provided features

• Extended features considered essential for your business

• Key integrations with your systems to get data that you require

Extended production release

This release includes the non-essential features that are defined during the solution proposal stage. Thefollowing features are implemented incrementally after the first production release:



• Non-essential Pega-provided features

• Extended features that you have identified as required for your business

This guide provides information to support both Scrum and Iterative Waterfall implementationmethodologies during the first production release and the extended production release.


Initiation stage

Initiation stageDuring this stage, the implementation teams build out the foundation or baseline of the application andprepare for the work that is necessary to configure the first production release and subsequent extendedproduction releases. For more information, see Implementation delivery methodology.

The Initiation stage includes the following tasks:

• Creating your application

• Customer sample data

• Enabling operator accounts

• Generating specification documents

Creating your applicationTo meet your organization needs, create your application on which your extended application will be built.Use the New Application wizard to create your new application.

When you run the New Application Wizard for Pega Smart Dispute for Issuers, it creates a set of Pega-provided access groups. You are required to create your own operators and add them to the requiredaccess groups.

Caution: If a Pega Smart Dispute for Issuers application already exists in your system, running theapplication wizard overwrites some existing application settings. This will cause issues with yourexisting application. Having more than one active Pega Smart Dispute for Issuers application on thesame Pega Platform instance is not supported. This includes custom applications built by you andsample applications provided by Pega.

1. Log in by entering an administrator user name and password. If you have enabled a sampleadministrative operator for this application, optionally log in using that operator ID.

2. In the Designer Studio header, click the name of your current application and click New Application tostart the wizard.

3. Follow the New Application wizard instructions.For more information, see Creating an application.

4. Enter the operator names or email addresses to invite users to work with your new application, andselect the corresponding role for each operator you set up.It is a best practice to create at least one operator in the application-specific administrator role for usein completing the implementation.

5. Optional: To fully set up your application, in the upper-right corner of Designer Studio, clickResources > Application Guides and follow the setup steps.

The New Application wizard creates the application class structure for you. You can reuse the classesand rulesets that are created by the wizard in future applications that you create. As you implementthis application and future applications, you can apply class hierarchy and inheritance principles to helpyou decide where in the class structure to create your rules to improve the maintainability and overallefficiency of your application.

For more information, see Class layers.


https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#rule-/rule-application/new.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#concepts/concepts2/conceptsclass.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#project-delivery/proj-class-layers-con.htm

Initiation stage

Customer sample dataPega Smart Dispute for Issuers includes sample data to support the Pega-provided demonstrationapplication. Pega recommends that you load customer-suppliedPega-provided sample data so thatimplementation efforts are more meaningful.

Enabling operator accountsTo use the sample application that you installed, enable the sample operator accounts that are includedwith the sample data.

1. Log in as the [email protected] operator with the password that you specified.

2. In the header of Dev Studio, click Configure > Org & Security > Authentication > Operator Access.

This page lists all currently disabled operator accounts.

3. In the Disabled operators section, click the link for the Pega-provided operator that you want toenable.

4. Optional: In the Contact Information section on the Profile tab, fill out any information that your siterequires.

5. On the Edit Operator ID page, on the Security tab, select the Force password change on next logincheck box and clear the Disable Operator check box.

6. Select Update password.

7. In the Change Operator ID Password window, enter a password that conforms to your site standardsand click OK.

8. Click Save to enable the operator record and the new password, and then close the page.

9. On the Organization and Security: Operator access page, repeat steps 2 through 7 for each operatorthat you want to enable.

For additional information, see Operator IDs.

Generating specification documentsTo avoid duplicating existing features, review the following documents to familiarize yourself with thedefault rules and rulesets of your application. During the solution assessment, a number of requirements,specifications, and other artifacts are captured to represent the scope of the work. If they are capturedin the Pega Platform, these artifacts can be reused to streamline the first production release scopeidentification.

You can export application specification and requirements artifacts from the Pega Platform, and thenimport them into your new baseline application so that you can build on the content that has alreadybeen created. For more information, see Exporting specifications and requirements and Importingspecifications and requirements.

Follow these procedures to generate documents that define what is contained within your application:

• Generating the Application profile

• Generating the Application document

• Generating the Specification document


https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#data-/data-admin-/data-admin-operator-/data-admin-operator-id/main.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#project-delivery/proj-exporting-specifications-and-requirements-tsk.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#project-delivery/proj-importing-specifications-and-requirements-tsk.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#project-delivery/proj-importing-specifications-and-requirements-tsk.htm

Generating the Application profileThis document is created during the Sales stage and includes the process stages and steps, case types,reports, requirements, specifications, participants, collaborators, and actors that are associated with theimplementation of your application. It is a document that defines the scope of the application, and it alsoincludes the results of the presale gap analysis.

When you generate this document, you can include process flow diagrams.

To generate the document, log into your application by entering your newly created credentials, andfollow the procedure in Generating an application profile document.

Generating the Application documentThis document and its associated controls provide the ability to customize the presentation of theapplication information based on the document's intended audience. When you run the ApplicationDocument tool, you can include or exclude content by selecting and clearing various options.

During an implementation, this document reflects the current state of your application. The ApplicationDocument tool automatically updates the content of your document as you modify and extend yourapplication to reflect additional requirements. If you have not yet built anything, the content of thisdocument is the same as the application profile.

To generate the document, log into your application by entering your newly-created credentials, andfollow the procedure in Generating an application document.

Generating the Specification documentThis document shows all of the specifications and linked requirements associated with your applicationat the time that you generate the document. You can generate this document at any point during theimplementation life cycle to include any updates to the application's specifications and requirements.

Review this document before and after each sprint by using the available filters to tailor the content tomeet the business requirements of your implementation.

To generate the document, log into your application by entering your newly-created credentials, andfollow the procedure in Generating a specification document.

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#project-delivery/document-application-tool/proj-generating-application-profile-tsk.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#project-delivery/document-application-tool/proj-generating-application-document-tsk.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#project-delivery/document-application-tool/proj-generating-specification-document-tsk.htm

Delivery stage

Delivery stageDuring this stage, the delivery team designs, builds, configures, and tests the application by using theselected implementation methodology. For more information, see Implementation delivery methodology.

The Delivery stage includes the following tasks:

• Defining requirements

• Building features

• Testing a new application

• Packaging a new application

Defining requirementsTo ensure that you stay on target for a successful deployment, use a structured approach for yourimplementation methodology. You will need to prepare for your implementation and determine keyaspects of the design that will affect the behavior of your application. Defining requirements for animplementation includes the following tasks:

• Reviewing extension requirements

• Refining customizations and determining the availability of required data and integrations

• Prioritizing, for example, revising the solution backlog, re-estimating the effort for extensions andcustomizations, and confirming the project scope

Defining your requirements also involves DCO sessions and incorporating those requirements into theapplication design. During these sessions, you review each of the case types and process flows that theapplication already provides.

Update the Application Specifications with planned changes as described in Specifications.

The Implementation Planning Workbook helps you capture decisions as you define your requirements. Youcan download the Implementation Planning Workbook from the Pega Smart Dispute for Issuers.

• Mapping your application data

• Defining integration

• Defining the case type modifications and attributes

• Application data model

• Defining the security model and organization structure

• Customizing the user experience

• Defining reporting requirements

• Defining accounting step rules

Mapping your application dataThe application data types provide a default set of properties for your use. You can add or removeproperties from these data types depending on your requirements. You can also add new data types.

Use the "Data model" worksheet in the Implementation Planning Workbook to record your decisions duringthis procedure.


https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#rule-/rule-application-/rule-application-usecase/main.htm

https://community.pega.com/knowledgebase/products/smart-dispute-issuers

Delivery stage

1. In the Designer Studio Explorer panel, click Data.

2. Click the data type that you want to modify.

3. On the Data model tab, determine the properties to add, remove, or leave unchanged. For moreinformation about data types, see Viewing data type details. Repeat these steps for any other datatypes, as necessary.

Defining integrationInventory the external applications that exist at your site and plan how to connect to them.

Note: Identify integration points as early in your planning as possible. If a connection to anexternal data source is required and either the data does not exist or the interface to that datadoes not exist, you must account for the time to publish these data sources and the time toconfigure the interface for this application.

The External Data Entities landing page lists the application data types and shows the source for that data.

To record your decisions during this procedure, use the "Integration" worksheet in the ImplementationPlanning Workbook.

1. Identify all integration points for your application.

2. Identify which data is needed from each system of record, if you have not already done so.

3. Determine whether an interface to that system of record already exists and how to connect to it.

Defining the case type modifications and attributesYour application includes a set of predefined case types. Each case contains one or more processes thatwill be extended or created to meet your business requirements. If you do not see an existing case type,you can create one during your planning process.

• Updating case types

• Adding case types

• Mapping case type or data type classes to a database table

Updating case typesIf an existing case type is close to meeting your business requirements, you can modify it and use it.

1. In the Designer Studio Explorer panel, click Cases.

2. Click the case type that you want to modify.

3. Update the settings for a case type.

4. Update the processes associated with the case type.In addition, you can add processes by using the Case Designer.

5. Repeat these steps for any other case types, as necessary.

Adding case typesIf you require a case type that is not similar to an existing case type, create a new one that meets yourbusiness requirements.

1. In the Designer Studio Explorer panel, click Cases.

2. Click Add a case type.


https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#designer-studio/data-designer/data-designer-viewing-data-type-details-tsk.htm

https://pdn.pega.com/viewing-external-data-entities/viewing-external-data-entities

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#case-management/case-designer/case-wide-properties/cm-categories-of-case-type-properties-ref.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#tools/caseexplorer/casedesigner.htm

Delivery stage

3. Enter the Name for the new case type.

4. Click Advanced Settings.

5. Select the Derived from (Directed) class.

6. Select the Derives from (Pattern) class.

7. Select the appropriate Ruleset and Ruleset version.

8. Click Submit.

9. Define a life cycle for the case type.

10. Click Finish.

Mapping case type or data type classes to a database tableWhen you run the New Application wizard to create your initial case types and data types, the systemcreates a default class group mapping for each case type and data type. The wizard also createsassociated database tables. The wizard maps the new implementation class to the appropriate databasetable.

Mapping a class to a physical database table affects data storage and security decisions. For example, ifyou expect the volume of the case types to be low, consider sharing the table with other case types.

To update the default database table to a user-specified database table, perform the following steps:

1. In the Designer Studio Explorer panel, click Records > SysAdmin > Database Table.

2. Open the class that you want to modify.

3. Review the default database name and the table name that the class points to.

4. To point the chosen database table to your specific class, edit the database name and table name.

5. To confirm your changes, click Save.

6. Click Test connection to check if the configuration succeeded. If the test results display errors, forexample, missing properties, review the data and correct them.

7. Update the class to point to the table specified above:

a) In the Designer Studio Explorer panel, click App.

b) Right-click the class name that you referred to in the steps above and select Definition.

c) On the General tab, click Test connection to check if the configuration succeeded.

8. Perform the steps above for the other case type or data type classes, if needed.

Application data modelThe application provides a set of data types, data pages, and sample data, which you can use to beginimplementing your application. . You will need to use the data from your system of record instead of usingthe sample data provided by the application.

To view the application data types and the currently configured sources for each data type, open theExternal Data Entities landing page.

Data modeling involves creating a conceptual model of how data items relate to each other in anapplication. In the Pega Platform, the data model refers to a set of rules that work together to populatethe data in your application. The system displays this data to help you process the information and canhelp you make decisions in your sales processes. The following rule types constitute your data model:

Data typesProperties


https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#case-management/case-designer/cm-defining-life-cycle-for-case-type-tsk.htm

Delivery stage

Data pages Data pages define the content of a clipboardpage. Data pages also control the loading of thatdata from a source system, as shown here.

When planning your data model, work with the data modeling resource at your site to understand theattributes of the data types that need to be supported by your application.

Defining data types

Defining the security model and organization structureSecurity planning involves defining authorization and authentication strategies for your application.

Authentication Proves to the application that you are who yousay you are.

Authorization Determines the functions that you can perform inthe application. This corresponds to access groupand role configuration.

Security planning also involves setting up the organization structure and operator attributes. Theapplication provides security in the form of access settings and denial rules. Many integration rules alsoincorporate authentication.

For more information about the additional aspects of security, enroll in the Lead System Architect course onPega Academy and cover the Security lessons that correspond to the following topics:

• Authentication schemes

• Defining your authentication scheme

• Defining your organization structure

• Defining the work groups

• Defining the work queues

• Defining work parties

Authentication schemesThe Pega Platform offers the following authentication types:

PRBasic Based on passwords in the Operator ID datainstances and the login form. This is defined bythe HTML @baseclass.Web-Login rule, whichyour application can override.


Delivery stage

PRSecuredBasic Similar to PRBasic, but passes credentials usingSecure Sockets Layer (SSL) using Basic HTTPauthentication. The login form is defined by theHTML @baseclass.Web-Login-SecuredBasicrule, which your application can override.

PRCustom Supports access to an external LDAP directory ora custom authentication scheme.

PRExtAssign Supports external assignments (Directed WebAccess).

J2EEContext Specifies that the application server in whichthe Pega Platform is deployed uses JAAS toauthenticate users.

Defining your authentication schemeYour site can use a centralized, automated means of maintaining operator data instead of maintaining itmanually in your application.

To record your decisions during this procedure, use the "Security Model" worksheet in the ImplementationPlanning Workbook.

1. Discuss Authentication schemes with your site's security and application server teams.

2. Determine the appropriate authentication type.

For more information on authentication scheme planning, see Authentication in Pega Platform.

Defining authorization scheme

Defining your organization structureUse the organization structure for routing and reporting within the application. Typically, the applicationorganization structure does not map operators exactly to the site's organization chart but instead, it mapsthe work that those operators do.

Tip: For design guidance, see Organization landing page.

Use the "Organization structure" worksheet in the Implementation Planning Workbook to record yourdecisions during this procedure.

1. Click Designer Studio > Org & Security > Organization > Organizational Chart.

2. Review the existing structure.

3. Determine the organization, division, and unit levels of the hierarchy.

Defining operator attributes

Defining the work groupsA work group determines which workbaskets you can access.

1. Click Designer Studio > Org & Security > Tools > Work Groups to display a list of associated workgroups.

2. Review and modify the list if necessary.

For more information, see About Work Group data instances.


https://pdn.pega.com/authentication-pega-7-platform/authentication-pega-7-platform-0

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#basics/v6portal/landingpages/orgsecurity/organization.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#data-/data-admin-/data-admin-workgroup/main.htm

Delivery stage

Defining the work queuesA work queue is a queue of open assignments in the application.

1. In the header of Dev Studio, click Configure > Org & Security > Tools > Work Queues to display a listof work queues.

2. Review and modify the list if necessary.

For more information, see Initial Work queues.

Defining work partiesA work party represents a person, business, or organization that is involved in a case. It receivescorrespondence, such as email, and can be an active or passive participant based on its role. Pega SmartDispute for Issuers comes with default work parties, but you might need to configure them for site-specific requirements.

1. In the Case types explorer, click the name of the case of which you want to modify the work parties.

2. Click the Settings tab and select Parties.

3. Click the work party name to open the settings for the work party.

4. Make your modifications and click OK.

For more information, see Defining the stakeholders of a case.

Customizing the user experienceWhile Pega Smart Dispute for Issuers is fully functional immediately after installation, you may changeportions of the user experience (UX) to meet the needs of the users at your site.

To design the user experience, complete the steps in the following topics:

• Designing portals

• Designing an application skin and styles

• Designing for screen performance

Designing portalsReview the content of the portals to ensure that only relevant data is presented.

To record your decisions during this procedure, use the "Portals" worksheet in the ImplementationPlanning Workbook.

1. From the Designer Studio Launch menu, select Case Manager 7.

2. Review each of the portal sections.

3. Repeat this process for the Dispute Manager portal.

Designing an application skin and stylesYour site very likely has user experience (UX) standards for the appearance of your applications. Your taskis to determine which styles have to change to adhere to those standards. To record your decisions duringthis procedure, use the "Skinning" worksheet in the Implementation Planning Workbook.

1. Click Designer Studio > User Interface > Skins, interfaces, & templates.

2. On the Skins tab, double-click the pyEndUser71 skin.


https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#data-/data-admin-/data-admin-workbasket/data-admin-workbasket.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#case-management/case-designer/case-wide-properties/work-parties/cm-adding-work-party-to-case-type-tsk.htm

Delivery stage

3. Click the Component Styles tab.

4. Review each component.

Note: As you plan your application styles, consider using mixins to provide incremental stylechanges. For more information, see Using mixins in the skin to drive consistency and efficiency.

Designing for screen performanceYou want your application to respond immediately as your end users interact with customers. As youdesign your user interface, complete the following steps:

1. Review transactional service level agreements. For example, the customer details must be available inone second or less while a representative is on the phone with the customer.

2. Review service performance, such as how long it takes back end systems to gather the data needed todisplay customer details.

3. Review data requirements to determine which fields contain the information that the representativesabsolutely need for the task that they need to perform.

4. Determine if any network configuration could cause latency, for example, if there are representativeslogged in through a corporate VPN or in a remote location.

Defining reporting requirementsBased on your login and portal, your application provides numerous pre-configured reports to monitorcase and work inventory as well as monitor workforce productivity and quality. These standard reportsare driven by the case and work object life-cycle infrastructure as well as the work and assignment-levelservice level rules for goals and deadlines used in managing the life cycle of a case.

Defining accounting step rulesAccounting step rules define which debit and credit transactions make up an accounting entry. There arethree accounting step rule classes, organized by the type of accounting steps:

• Rule-PegaAcct-Financial-Adjustment: for an adjustment

• Rule-PegaAcct-Financial-Payable: for a payable suspense

• Rule-PegaAcct-Financial-Receivable: for a receivable suspense

The classes share the same class structure (including the key structure) and are used in identical waysto create the information in an accounting step. The key consists of the work object class for whichaccounting is being processed, an accounting action (different for a suspense transaction versus anadjustment transaction), and a type that specifies a name for the particular rule.

To define the accounting step rules:

1. Download the Accounting step rules spreadsheet from the Smart Dispute for Issuers product page. Useof this spreadsheet is optional.

2. Plan the step rules with the bank.The actual configuration of the step rules will take place in the Setting up account step rules task.

Building featuresTo build your application features, complete the steps in the following topics:

• Modifying the class structure


https://pdn.pega.com/using-mixins-skin-drive-consistency-and-efficiency

https://pdn.pega.com/products/smart-dispute-issuers

Delivery stage

• Implementing the security model

• Modifying the user interface

• Reports

• Configuring the dispute main flow

• Implementing Visa Claims Resolution (VCR)

• Implementing MasterCom Claims Manager (MCOM)

• Configuring application fraud properties

• Setting up correspondence verification

• Modifying automatic correspondence

• Modifying automatic correspondence generation

• Modifying the OnUs decision map

• Modifying dispute qualification scripts

• Setting up duplicate scoring rules

• Modifying multiple partial dispute values

• Configuring reassertion values

• Defining new bank identification numbers

• Configuring approval flows

• Working with accounting functions

• Integrating data

• Configuring integration components

Modifying the class structurePega Smart Dispute for Issuers automatically creates your class structure. When you modify the structure,follow the correct naming conventions. For more information, see Classes.

Implementing the security modelAfter you review the existing groups and roles to determine additional groups and roles that you need,create them by clicking Designer Studio > Org & Security > Groups and Roles. Make sure that you arelogged in as an administrator. For information on configuring groups and roles, see Groups and Roles andrelated topics.

Modifying the user interfaceTo modify the user interface, complete the steps in the following topics:

• Determining which part of the user interface to modify

• Locating the user interface element to change

• Adding properties to sections

• Adding sections

• Updating the skin


https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#rule-/rule-obj-/rule-obj-class/main.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#basics/v6portal/landingpages/orgsecurity/security.htm

Delivery stage

Determining which part of the user interface to modifyWhen you first access your application portal, you see the dashboard, which typically contains anavigation panel on the left. The content of the dashboard is customizable and displays any data that youintegrate into your application.

Locating the user interface element to changeTo determine which user interface element to modify to implement your change, use the Live UI featureof the Pega Platform.

1. In Designer Studio, launch a portal.

2. Click the Live UI icon.

3. Select an element to observe. When selected, the Live UI icon provides the information about the UIelement. You can see the sections and harnesses of the element.

4. To update the rule, click the Open in Designer Studio icon.

Adding properties to sectionsPega Smart Dispute for Issuers uses standard Pega Platform user interface components, so the updateprocess is the same as any Pega Platform application.

1. In Designer Studio, click Live UI and determine the section that you want to modify.

2. To open the rule in Designer Studio, click the Magnifying glass icon.

3. In the Application Explorer, locate the property that you want to add to the section and drag it into thatsection.

4. Click Save as and then save the rule to the default Applies To class and make sure that the ruleset is foryour application.

5. Click Create and open and click Save.

Adding sectionsPega Smart Dispute for Issuers uses standard Pega Platform user interface components, so whether youare updating the dashboard, portals, or the composite, you do so in the same way as any Pega Platformapplication.

1. In Designer Studio, click Live UI and locate the section where you want to add another section.

2. To open the rule in Designer Studio, click the Magnifying glass icon.

3. In the Application Explorer, locate the section that you want to add and drag it into your specifiedsection.

4. Click Save as and save the rule to the default Applies To class. Make sure that the ruleset is for yourapplication.

5. Click Create and open and then click Save.

Updating the skinYou can update the look and feel of Pega Smart Dispute for Issuers to reflect the color scheme of yourorganization. The application uses the standard Pega Platform skinning features in your application.

For more information about skins, see Creating a skin and Skin inheritance.

1. In Designer Studio, click Application Name > Skin.

2. Click Create and open.


https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#ui/ui-skin/ui-skin-creating-tsk.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#ui/ui-skin/skin-inheritance/ui-skin-inheritance-con.htm

Delivery stage

3. If you give your skin a different name, update the application to reflect it by performing the followingsteps:

a) In Designer Studio, click Application Name > Open Application.

b) Change the value in the Skin field to the name of the skin that you created.

4. Click Save.

ReportsIn addition to the library of Pega Platform reports, Pega Smart Dispute for Issuers provides several pre-configured reports that are customized for the various work objects, cases, and business processes usedin the application. These reports provide you with real-time insights into case inventories and aging sothat you can respond with the agility that is needed to comply with your internal and external service levelagreements as well as compliance mandates.

To create other reports, see Reporting.

Configuring the dispute main flowProcessing in Pega Smart Dispute for Issuers is controlled by flows that determine which screens you seeand which processing occurs in the background. Pega Smart Dispute for Issuers processing begins withthe DisputeMainFlow flow rule, which calls multiple additional business processing flows, depending onthe exact details of the dispute that you enter.

For more detailed information about the Dispute main flow, see Smart Dispute for Issuers - Dispute mainflow.

Do the following steps to configure the main flow.

• Modifying the provisional credit decision tree

• Configuring automatic write-off criteria

• Configuring Regulation Z requirements

• Configuring debit transaction dispute processing

• Configuring Regulation E requirements

• Modifying the Close Claim action

• Configuring High Number of Disputes processing

• Modifying the Manual Case Creation section

Modifying the provisional credit decision treeThe Provisional Credit decision tree evaluates a work object based on product type such as Gold or VIP,value, and dispute history to determine whether provisional credit should be given to the cardholder.Pega Smart Dispute for Issuers comes with a provisional credit decision tree that you can use or modify ifyour business rules change.

1. In the Designer Studio header search text field, enter IsProvisionalCredit and select the decisiontree.

2. Click Save as.

3. Click Edit to edit the Identifier name.

4. In the Apply to field, enter the respective class name.

5. Select a ruleset from the Add to ruleset list, and click Create and open.


https://pdn.pega.com/reporting

https://pdn.pega.com/smart-dispute-issuers-dispute-main-flow

https://pdn.pega.com/smart-dispute-issuers-dispute-main-flow

Delivery stage

6. Edit the If statements as needed.

• Enter a comparison starting with one of the comparison operators <, >, <>, =, == (Java identity), >=or <=. If you do not start the expression with an operator, the system assumes =.

• Typically, you should follow the comparison operator with a literal value between quotation marks,or a scalar string property reference.

• Modify the values for cardholder value, account details, dispute amount, fraud indicator, and resultcount.

7. Click Save.

Configuring automatic write-off criteriaA bank may have a policy that states that unresolved suspense entries are written off if the amountinvolved is below a certain threshold. A write-off occurs when the cost of processing is far more than thevalue of the dispute itself. For example, a bank may set a low dollar write-off amount at $10, because itis either less expensive for them to take the loss than it is to process it through the associations, or it isnot worth potentially upsetting a customer over a small amount. Examine, and if necessary, adapt thefollowing write-off rules:

• Setting up the write-off criteria for entry evaluation

• Setting up the write-off criteria for lower thresholds

• Setting up the write-off criteria for service levels

• Setting up the write-off criteria for aging thresholds

Setting up the write-off criteria for entry evaluationPega Smart Dispute for Issuers performs an evaluation for write-off after a dispute has been qualified.The IsWriteOff decision tree is used to evaluate whether the dispute should be written off, based oncriteria such as account details, amount, and dispute history. The write-off workflow uses the write-offdecision tree to capture best practice business logic and uses it to make automated decisions.

1. In the Designer Studio header search text field, enter IsWriteOff and select the decision tree fromthe results.

2. Click Save as.




6. Edit the If statements as needed.

• Enter a comparison starting with one of the comparison operators <, >, <>, =, == (Java identity), >=or <=. If you do not start the expression with an operator, the system assumes =.

• Typically, you should follow the comparison operator with a literal value between quotation marks,or a scalar string property reference.

• Modify the values for cardholder value, account details, dispute amount, fraud indicator, and resultcount.

7. Click Save.


Delivery stage

Setting up the write-off criteria for lower thresholdsA map value threshold is used whenever a Lower entry type for a suspense account is created on adispute. The default value is $0.00. For example, after a partial chargeback the value defined in theWriteOffOnLower threshold determines if the remainder should be automatically written off.

1. In the Designer Studio header search text field, enter WriteOffOnLower and select the map valuefrom the results.

2. Click Save as.




6. Enter a new write-off threshold.

7. Click Save.

Note: You can define different thresholds for different work object classes by creating these mapvalue rules in the specific work object classes.

Setting up the write-off criteria for service levelsYou can configure a service level agreement (SLA) value on open suspense items. Pega Smart Disputefor Issuers uses the ReceivableWriteOffSLA service level rule, which is found in the PegaCard-Sd-Dispute class. Service levels define two time intervals, a goal and deadline, that can trigger escalation(and other tasks) when their thresholds are crossed.

The default write-off period is 180 days, at which time Pega Smart Dispute for Issuers suggests that anopen suspense item should be written off �" which closes items when the likelihood of recovering fundsis low.

1. In the Designer Studio header search text field, enter ReceivableWriteOffSLA and select theservice-level agreement rule from the results.

2. Click Save as.




6. Update the Goal and Deadline values as necessary.

7. Click Save.

Setting up the write-off criteria for aging thresholdsThe time period that an open suspense accounting item must wait, or age, before being written offis determined by two MapValue rules, ReceivableWriteOffSLA (for receivable accounting) andPayableWriteOffSLA (for payable accounting).

1. In the Designer Studio header search text field, enter either PayableWriteOffSLA or .ReceivableWriteOffSLA and select the service-level agreement from the results.

2. Click Save as.




6. You can specify an age threshold or you can set the age threshold based on the outstanding balance.


Delivery stage

7. Click Save.

Configuring Regulation Z requirementsPega Smart Dispute for Issuers is compliant with US Regulation Z (Reg Z). You can extend and modifyconditions to satisfy individual banks’ compliance guidance and policies.

A dispute is subject to Reg Z regulation if all the conditions in the When rule, IsSubjecttoRegZ aresatisfied:

• Account is a credit card account

• Issuer BIN is a US BIN

• Transaction date falls within the last two billing cycles

• Account is not a business account type

To configure Regulation Z requirements, complete the following tasks:

• Modifying the service-level agreement final date

• Modifying the audit trail

Modifying the service-level agreement final dateThe RegZFinalitySLA service-level agreement is configured, so that appropriate action is taken whenthe dispute reaches Reg Z Final date. The goal is defined as two days prior to the Reg Z Final date. TheDeadline is defined as the Reg Z final date. Review these values with the bank and modify them asnecessary.

1. In the Designer Studio header search text field, enter RegZFinalitySLA and select the service-levelagreement from the results.

2. Click Save as.


4. In the Apply to field, enter the applicable class name.


6. Modify the goal, as necessary.The calculation for the deadline date should never change.

7. Click Save.

Modifying the audit trailReview the audit trail with the bank and add history items, if necessary.

1. In the Designer Studio header search text field, enter d_pyworkhistory and select the data page fromthe results.

2. Click Save as.




6. Add history items, as necessary.

7. Click Save.


Delivery stage

Configuring debit transaction dispute processingThe processing flow for debit processing (ACH, ATM, and debit pin and pinless transactions) begins withthe DisputeMainFlow, but branches off depending on the transaction.

Debit card and deposit account transaction disputes inherit from the PegaCard-Sd-Debit classes.In order to provide the correct processing, make sure your extended class structure is designedappropriately to inherit the correct processing rules.

Do the following tasks to configure debit transaction dispute processing.

• Setting up the write-off criteria for debit transaction disputes

• Adding conditions for Automated Clearing House commercial dispute handling

• Reviewing the ACH dispute reason codes

• Configuring ATM processing reason codes

• Reviewing Interlink and Maestro reason codes

• Reviewing Pinless (Signature) reason codes

Setting up the write-off criteria for debit transaction disputesYou can set the distinct write-off criteria for debit or deposit account disputes in the IsWriteOff decisiontable.

1. In the Designer Studio header search text field, enter IsWriteOff and select the PegaCard-Sd-Debit decision table from the results.

2. Click Save as.




6. Edit the levels, if needed.

7. Click Save.

Adding conditions for Automated Clearing House commercial dispute handlingThe IsCommercialDispute when rule in the PegaCard-Sd-Debit-ACH class evaluates the SEC code todetermine if the transaction should be processed as a commercial dispute.

If the SEC code is CCD, the Automated Clearing House (ACH) returns the R05 reason code. If the SECcode is CTX the ACH returns the R31 reason code. For either of these SEC codes, the customer isgiven immediate credit and the dispute status is Resolved-WrittenOff. This is managed by theCommercialDisputeFlow in the PegaCardSdACH class.

1. In the Designer Studio header search text field, enter IsCommercialDispute and select thePegaCard-Sd-Debit-ACH when rule from the results.

2. Click Save as.




6. Add criteria for evaluation, if necessary.

7. Click Save.


Delivery stage

8. Repeat the previous steps for the CommercialDisputeFlow flow rule, to extend the flow to includebank-specific actions. Modify the flow, as necessary.

Reviewing the ACH dispute reason codesThe qualify dispute and return code selection steps are combined in the ReturnCodeAdvisor flow.Specific ACH return reason codes have been configured using the standard reason code rule forms.

1. In the Designer Studio header search text field, enter ReturnCodeAdvisor and select the PegaCard-Sd-Debit flow rule from the results.

2. Review the ACH return reason codes with the customer. Do not modify these rules as the specificinformation about each return reason code and subsequent action is determined by National ClearingHouse Association (NACHA). If the bank believes they are not configured using the association rules,open a Service Request with Global Customer Support and the Pega Smart Dispute for Issuers productteam will review and address as appropriate.

Configuring ATM processing reason codesSample reason code rules for Pulse and On-Us ATM transactions are already configured. ATM reasoncodes include Wrong Amount, Duplicate Transaction, and Do Not Recognize. You can extend theserules for other error descriptions, as well as for other ATM networks in which the bank participates.

1. In the Designer Studio header search text field, enter the return code you want to modify, and selectthe PegaCard-Sd-Debit dispute return code rule from the results.

2. Click Save as.




6. If the bank wants to add additional error descriptions for ATM processing, create new ATM reason coderules using the sample reason code rule as a template.

7. Click Save.

Reviewing Interlink and Maestro reason codesPega Smart Dispute for Issuers includes reason code rules for Visa's debit card network Interlink, andMaster Card's debit network Maestro.

1. In the Designer Studio header search text field, enter the return code you want to review, and selectthe PegaCard-Sd-Debit dispute return code rule from the results.

2. Review, but do not modify these rules. If the customer states they are not configured per theassociation rules, open a Service Request with Global Customer Service and the Pega Smart Dispute forIssuers product team will review and address as appropriate.

Reviewing Pinless (Signature) reason codesPega Smart Dispute for Issuers includes reason code rules for Visa and Master Card, along with ReasonCode Advisor to help dispute operators correctly select the appropriate reason code.

1. In the Designer Studio header search text field, enter the reason code you want to review, and selectthe dispute reason code rule from the results.

2. Review, but do not modify these rules. If the customer states that they are not configured per theassociation rules, open a Service Request with Global Customer Service and the Pega Smart Dispute forIssuers product team will review and address as appropriate.


Delivery stage

Configuring Regulation E requirementsRegulation E (Reg E) processing in Pega Smart Dispute for Issuers includes many configurable options, sothat a bank can comply with the regulation but remain consistent with the bank's policies.

• Configurable Attestation and Written Notification options.

• Ability to attest in self-service portal.

• SLA rules to ensure provisional credit is given within Reg E time lines.

• Decision rules to configure provisional credit automatically or manually.

• Landing page for configuring Reg E processing rules.

To configure Reg E requirements, complete the following tasks:

• Modifying Regulation E decision rules

• Modifying Regulation E document receipt service-level agreement rules

• Modifying Regulation E at the claim level

• Modifying the reverse provisional credit service-level agreement

• Setting up process fees in debit disputes

Modifying Regulation E decision rulesReview the Regulation E (Reg E) rules to ensure that they are compliant with the bank's policies.

1. Click Designer Studio > Smart Dispute Configurations > RegE.

2. Use the Reg E control panel to review the following rules and modify them if necessary.

Written Notification (WrittenNotificationRequired )

Used to configure the conditions in whicha customer is required to provide writtennotification.

Attestation criteria (VerbalAttestationRequired )

Can be used for extending the criteria underwhich attestation assignment is displayed.

Immediate Provisional Check (ImmediatePCAndDocCheck )

Used for evaluating if provisional credit canbe given can be given immediately at thetime of case creation.

RegE Eligibility Criteria ( RegEEligible ) Used to check if dispute is eligible for Reg Eprocessing.

Deposit Account The When rule checks whether the accountholder's primary address has a country codeof US, and that the account type is checkingor savings.

Transaction Date The NoRegECreditDate data transformrule determines the date before whicha transaction is not subject to Reg Eprocessing. This is done by readingthe account's statement cycle date,and calculating the first date of thesecond to the last statement. TheIsRegECreditRequired When rulecompares NoRegECreditDate to thetransaction date to determine if the disputeis subject to Reg E requirements.


Delivery stage

Additional RegE eligibility notification (IsEligibleForREGEPC )

When rule used to configure additionalcriteria for giving provisional credit.

Note: The PCAmountAvailable property rule is used to track whether or not the Provisionalcredit amount is available. A value of true is required to give Provisional Credit automatically.Similarly, the IsThirdPartyResNetworkEligible property is used to identify if the merchantis registered with a third party dispute resolution network (for example, Verifi). A value of falsefor this property is required to ensure automatic provisional credit. Both of the properties areset in the SetPCAmtAvailable data transform rule.

Note: If you are handling ACH disputes, check the setting of the written notification flag. TheWritten Notification flag is not checked during ACH flows because the customer is requiredto either verbally attest or send a written statement of unauthorized debit (WSUD). Disablingattestation makes WSUD mandatory.

Modifying Regulation E document receipt service-level agreement rulesUse the WaitForDocument service-level agreement rule to determine whether a customer has sentthe written notification on time. If the dispute is eligible for Regulation E processing and the documenthas not been received by the RegEPC date, then the RegEPC date is blanked out for audit and reportingpurposes and GivePC assignment will be removed.

1. In the Designer Studio header search text field, enter WaitForDocument, and then select theWaitForDocument service-level agreement rule from the results.

2. Click Save as.




6. Review the goals and post actions and modify them as needed.

7. Click Save.

Modifying Regulation E at the claim levelYou can have disputes that have a 45-day final date and disputes that have a 90-day final date on oneclaim. If so, you can either manage by dispute, or by the claim. If you manage by the claim, you have tomanage by the most restrictive date, therefore you must override the 90-day claim-level date.

If you manage by dispute, then you have to leave the claim itself open until all disputes have beenresolved.

Regulation E (Reg E) dates for each dispute are set after transaction selection, along with claim-levelRegEPC, WaitForRegEFinal45 and WaitForRegEFinal90 dates. Service-level agreements are setfor each claim-level Reg E date, so that the claims can be managed from the user’s worklist. If a set ofdisputes in a claim include no disputes with a Reg E final date of 90 days, then that property and service-level agreement are not set.

1. In the Designer Studio header search text field, enter either WaitForRegEFinal45 orWaitForRegEFinal90 and then select the service-level agreement rule from the results.

2. Click Save as.




6. Review the WaitForRegEFinal45 or WaitForRegEFinal90 dates and modify the goal dates ifneeded.


Delivery stage

Caution: You should never modify the deadline dates.

7. Click Save.

Modifying the reverse provisional credit service-level agreementRegulation E specifies that if you reverse provisional credit because you find the customer liable, youmust notify the customer within a minimum of 5 business days that you will be reversing the credit. TheReverse Provisional Credit action sends the notification to the customer about the reversal, and sets theReverseProvisionalCredit service-level rule on the 5th business day. The reversal accounting entry iscompleted with the completion notice sent to the customer.

1. In the Designer Studio header search text field, enter ReverseProvisionalCredit and select the service-level agreement rule from the results.

2. Click Save as.




6. Change the default 5 day rule to a longer time period if needed.Under RegE rules, time period cannot be shorter than 5 days.

7. Click Save.

Setting up process fees in debit disputesRegulation E requires the return of fees and interest if they were caused by a disputed transaction. Priorto granting provisional credit for debit transactions, Pega Smart Dispute for Issuers simulates integrationto the bank's deposit account system to return any fees posted to the account since the transaction date.The user can decide if any or all of these various fees need to be credited back to the customer.

1. In the Designer Studio header search text field, enter SelectChargeFees and select the PegaCard-Sd- flow from the results.

2. Click Save as.




6. Add integration points, if necessary, to retrieve fees from the bank's deposit account system. You canalso review the manual entry screens within the flow and modify them as appropriate.

7. Click Save.

Modifying the Close Claim actionThe Close Claim claim-level action is available once all disputes have a resolved status. The action allowsyou to select the claim status from a drop-down list.

1. In the Designer Studio header search text field, enter CloseClaimResolutionStatus, and thenselect the property rule from the results.

2. Click Save as.





Delivery stage

6. Review the statuses and modify them as needed.

7. Click Save.

Configuring High Number of Disputes processingA dynamic system setting rule, HNDLimit, holds the transaction count (integer, up to 9999) to evaluateHigh Number of Disputes (HND) processing. By default, the value is set to 25.

1. In the Records Explorer, click SysAdmin > Dynamic System Settings.

2. Select the HNDLimit dynamic system setting.

3. Edit the default value, if necessary. You have the following options:

• Empty/blank value – disables HND processing

• 0 – Always create disputes in background

• n – If selected transactions count is greater than or equal to the number provided, then the HNDprocessing/feature will be enabled

4. Click Save.

Modifying the Manual Case Creation sectionA Disputes operator can create a case for a customer even if they cannot find the underlying transaction(because of systems issues or other posting problems). As a result, they can keep track of the customer’sproblem, meet regulatory and policy rules, and solve the problem for the customer.

Review this section rule, and add fields if needed.

1. In the Designer Studio header search text field, enter TransactionDetailsEntry and select thesection rule from the results.

2. Click Save as.




6. Add fields to the section, if needed.

7. Click Save.

Implementing Visa Claims Resolution (VCR)Visa Claims Resolution (VCR) simplifies the way exception transactions are processed and automatesdecisions by moving from a litigation-based model to a claims-based (liability assignment) model.

VCR high-level process flow

• VCR High-level flow VCR eligibility check

• Tran Inquiry

• Dispute category and dispute reason questionnaire

• Pending Visa or Acquirer response

• System or back office user processes response

• Accounting

Complete the following steps to configure VCR.


Delivery stage

• Reviewing VCR business configurations

• Configuring the Allocation Liability SLA

• Configuring the Inbound Pre-arbitration SLA

• Configuring the Collaboration Liability SLA

• Configuring the Outbound Pre-arbitration SLA

• Configuring the Arbitration SLA

• Disabling VCR simulations

• Reviewing VCR services

• Reviewing VCR data transform rules

• Configuring VCR SOAP service connections

Reviewing VCR business configurationsPega Smart Dispute for Issuers identifies whether a dispute is qualified to be processed through the VCRpath based on rules that are set up for each country that is migrating to VCR.

Note: The VCRDateForHK_NZ rule Might is set to September 1, 2016, so that you can simulate VCReligibility for testing and training purposes. You will need to update this date if you issue cards inthose regions.

1. In the Designer Studio header search text field, enter the name of a when rule for a country you wantto review, for example VCRDateForHK_NZ and select the PegaCard-Sd-Dispute-Visa when rulefrom the results.

2. Click Save as.




6. Confirm the dates with the bank.

7. Click Save.

8. Repeat the previous steps for the VCRDateForUS_AUS_CANADA when rule.

Configuring the Allocation Liability SLAThe Allocation Liability service level agreement (SLA) is used for Allocation flows. It is triggered once thedispute is submitted and waits for the acquirer’s response. By default, the goal and deadlines are set to 30days based on Visa guidelines.

1. In the Designer Studio header search text field, enter AllocationLiabilitySLA and select thePegaCard-Sd-Dispute-Visa service level agreement rule from the results.

2. Click Save as.




6. Review the goal and the deadline. Adjust the goal, if necessary.

Important: Do not adjust the deadline value. It is set by Visa.

7. Click Save.


Delivery stage

Configuring the Inbound Pre-arbitration SLAThe Inbound Pre-arbitration service level agreement (SLA) is triggered when an acquirer initiates a pre-arbitration request. By default, the goal and deadlines are set to 30 days based on Visa guidelines.

1. In the Designer Studio header search text field, enter InboundPreArbitration and select thePegaCard-Sd-Dispute-Visa service level agreement rule from the results.

2. Click Save as.






7. Click Save.

Configuring the Collaboration Liability SLAThe Collaboration Liability service level agreement (SLA) is used for collaboration flows. It is triggered oncethe dispute is submitted and waits for the acquirer’s response. By default, the goal and deadlines are setto 30 days based on Visa guidelines.

1. In the Designer Studio header search text field, enter CollaborationLiabilitySLA and select thePegaCard-Sd-Dispute-Visa service level agreement rule from the results.

2. Click Save as.






7. Click Save.

Configuring the Outbound Pre-arbitration SLAThe Outbound Pre-arbitration service level agreement (SLA) is used for processing pre-arbitrationrequests initiated by an issuer. It is triggered if an issuer initiates a pre-arbitration request. By default, thegoal and deadlines are set to 30 days based on Visa guidelines.

1. In the Designer Studio header search text field, enter VCROutboundPreArbSLA and select thePegaCard-Sd-Dispute-Visa service level agreement rule from the results.

2. Click Save as.






7. Click Save.


Delivery stage

Configuring the Arbitration SLAThe Arbitration service level agreement (SLA) is initiated by an issuer. By default, the goal and deadlinesare set to 10 days based on Visa guidelines.

1. In the Designer Studio header search text field, enter VCRArbitrationSLA and select the PegaCard-Sd-Dispute-Visa service level agreement rule from the results.

2. Click Save as.






7. Click Save.

Disabling VCR simulationsVCR disputes can be processed in a simulation mode without connecting to Visa in real time. Thissimulation feature can be especially useful for testing and training activities. Simulations are turned on bydefault. To disable simulations, do the following steps.

1. Click Designer Studio > Smart Dispute Configurations > VCR Configurations .

2. Click Disable.

3. Click Close.

Reviewing VCR servicesPega Smart Dispute for Issuers has implemented services to connect to Visa VROL services for disputeprocessing, per the RTSI Schema, as part of the VCR integration.

1. In Designer Studio click Data > Pega VCR Services.

2. Review the CSR services and modify the simulated data transforms for testing and training purposes.

ServiceKey The primary data type key which refers to theVCR service name

RequestDataTransformRuleName Stores the data transform which is used tobuild the request XML for the respectiveservice being referred to in the record

ResponseDataTransformRuleName Stores the data transform which is used toparse the response XML for the respectiveservice being referred to in the record

SimulatedRequestDTRuleName Stores the simulated data transform which isused to build the sample simulated requestXML for the respective service being referredto in the record

SimulatedResponseDTRuleName Stores the data transform which is used toparse the sample simulated response XMLfor the respective service being referred to inthe record


Delivery stage

SOAPServiceClassName Refers to the class in which the respectiveservice is available based on the WSDLprovided by Visa

ScenarioName Non-mandatory respective servicesreferencing scenario. It is used only forfunctional reference and does not carry anytechnical significance

Reviewing VCR data transform rulesPega Smart Dispute for Issuers sends a request XML using a service to VCR-VROL (Visa Resolve Online)and awaits response from VROL. Once response is received, the application resumes the respective flowand continues the dispute process.

When VCR simulation is enabled, Pega Smart Dispute for Issuers does not connect to Visa with a requestXML. Instead, the application simulates the outcome using the simulated data transforms.

For example, while submitting the SISubmitDisputeQuestionnaireRequest dispute questionnaire istriggered from the application as a request that is sent to Visa in real time with the dispute questionnairedetails. VCR-VROL sends SISubmitDisputeQuestionnaireResponse as the response for the request.

When using the simulation mode, VCR-VROL is not connected online. Instead, a simulated response withinthe application gets triggered for the submitted request. The mapping for the simulated responses forrespective requests is maintained in the VCR services data type as mentioned above.

Review the simulated responses, such as the SimulateVCR_SubmitDisputeQuestionnaireRes datatransform.

1. In the Designer Studio header search text field, enter the name of a data transform rule you want toreview, for example SimulateVCR_SubmitDisputeQuestionnaireRes and select the PegaCard-Sd-Dispute-Visa data transform rule from the results.

2. Click Save as.




6. Review the data transform with the bank.

• If the VROLFinancialSentInd field has a True/False value, then accounting is required which impliesthat the acquirer is liable for the dispute initiated.

• If the VROLFinancialSentInd field is blank, no accounting is required which implies that the issueris liable for the dispute initiated.

• To simulate an Issuer liable scenario for one of the transactions with ARN24610432650004020160841, leave the VROLFinancialSentInd field empty. For all others this fieldcarries the value of true which makes the acquirer responsible.

7. Click Save.

Note: There are multiple simulated data transforms that are shipped with the application inthe Pega VCR Services data type. These services can be used to simulate various responses fromVisa for testing purposes, and updated to simulate different responses, in the absence of Visaconnectivity.


Delivery stage

Configuring VCR SOAP service connectionsTo securely communicate with Visa Claims Resolution (VCR) SOAP services, Visa requires a two-way SSLauthentication.

To configure an SSL connection between Pega Smart Dispute for Issuers and VCR, do the following tasks.

• The Configuring the VCR Authentication Profile

• Uploading the VCR web services keystore file

• Uploading the VCR web services truststore file

• Verifying the VCR RTSI endpoint URLs

The Configuring the VCR Authentication ProfileVisa provides a user name and password for authentication. Add these credentials to the AuthenticationProfile rule.

Note: The profile is also configured in the VCR SOAP Services, as part of the SOAP request header.

1. In the Designer Studio header search text field, enter VCRAuthenticationProfile and select theauthentication rule from the results.

2. Click Save as.




6. Enter the Visa-provided user name in the User name

7. Click Set password, enter your Visa-provided password, and click Submit.

8. Click Save.

Uploading the VCR web services keystore fileVisa provides a web services keystore ( .pfx ) file that contains both private keys and certificates. Uploadthis file to the VCRKeystore rule.

Note: The VCRSecurityProfile rule contains references to both the VCR Keystore andTruststore.

1. In the Designer Studio header search text field, enter VCRKeystore and select the keystore rule fromthe results.

2. Click Save as.




6. Click Upload file and browse to the Visa-provided .pfx file.

7. Enter the Keystore type and the Visa-provided password.

8. Click Save.


Delivery stage

Uploading the VCR web services truststore fileVisa provides a web services truststore ( .jks ) file. You can use this file, or the exact root andintermediate certificates from the keystore .pfx. If you use the latter method, your can use a Java keytoolor OpenSSL. This task describes using the ( .jks ) file.

Note: The VCRSecurityProfile rule contains references to both the VCR Keystore andTruststore.

1. In the Designer Studio header search text field, enter VCRTruststore and select the keystore rulefrom the results.

2. Click Save as.




6. Click Upload file and browse to the Visa-provided .jks file.

7. Enter the Keystore type and the Visa-provided password.

8. Click Save.

Verifying the VCR RTSI endpoint URLsThe VCR Real-Time System Interface (RTSI) endpoint URLs are saved in the dynamic system setting rules.Open these rules and verify the URLs.

The D_GetVCREndpointURLs data page loads the endpoint URLs. The GetVCREndpointURLs datatransform fetches these URLs from the dynamic system settings.

1. In the Designer Studio header search text field, enter VCR_RolSI_Endpoint, VCR_RolTI_Endpoint,or VCR_RolVCR_Endpoint and select the dynamic system setting rule from the results.

2. Click Save as.




6. Review the endpoint URL and modify it, if necessary.

7. Click Save.

Implementing MasterCom Claims Manager (MCOM)The MasterCom API offers Mastercard customers the ability to create and manage dispute claims inMasterCom. Issuers, acquirers and processors can integrate these APIs into their platform to fulfill disputemanagement needs. Complete the following steps to configure MCOM.

• Enabling the MasterCom interface

• Enabling service request and response logging

• Configuring the MCOM authentication profile

• Toggling simulation mode

• Configuring simulated data transforms

• Defining custom workbaskets

• Extending service call request response


Delivery stage

• Configuring request post-processing

• Configuring response post-processing

• Configuring documents at the reason code level

• Configuring ancillary questions at the reason code level

• Configuring dispute validations at the reason code level

Enabling the MasterCom interfaceEnable the MasterCom interface to route all disputes through the new Claims Manager.

1. Click Designer Studio > Smart Dispute Configurations > MCOM Claims Manager Configurations.

2. Next to the Enable MCOM option, click Enable.

Enabling service request and response loggingTo capture the MasterCom Claims Manager request and response information, enable the service requestand response logging dynamic system setting.


2. Next to the Enable MCOM Audit, click Enable.

Complete the following steps to customize the audit logging logic and hide sensitive information from theaudit logs:

• Customizing audit logging

• Hiding sensitive information from audit logs

Customizing audit loggingCustomize the LogMCOMClaimsMgrSvcInvocationExtension data transform by adding any customlogic that may be required for your implementation.

1. In the Designer Studio header search field, enter LogMCOMClaimsMgrSvcInvocation and, from thesearch results, select the LogMCOMClaimsMgrSvcInvocation data transform.

2. In step 19 of the data transform, click the Open icon to open the referenced data transform.

3. Add any custom logic that may be required for your implementation to theLogMCOMClaimsMgrSvcInvocationExtension data transform.

Hiding sensitive information from audit logsCustomize the GetSanitizedJSONForMCOMLogging data transform to hide any sensitive information(for example, account and card numbers) from the audit logs.

1. In the Designer Studio header search field, enter GetSanitizedJSONForMCOMLogging and, from thesearch results, select the GetSanitizedJSONForMCOMLogging data transform.

2. Click the Settings tab and add the fields that you do not want to appear in the audit logs:

a) Under Fields to skip when auto-mapping, click Add field.

b) In the empty text field, type the name of a field to skip.

3. Click Save.


Delivery stage

Configuring the MCOM authentication profileEnable MasterCom Claims Manager audit, authorization and clearing data, and set up authenticationparameters.

Ensure that service request and response logging is enabled. See Enabling service request and responselogging.


2. Next to Enable Authorization & Clearing Data, click Enable.

Complete the following steps to set up authentication parameters:

• Configuring the base URL

• Configuring the keystore

• Configuring the consumer key

• Configuring the key alias

Configuring the base URLBy default, the MasterCom Claims Manager base URL is set to the MasterCard sandbox environment. Fora production setup, update the base URL with the correct value.

1. In the Designer Studio header search field, enter MCOMClaimsMgrBaseURL and, from the searchresults, select the PegaCardSdMasterCard MCOMClaimsMgrBaseURL dynamic system setting.

2. In the Value field, type the MasterCom Claims Manager services base URL.

3. Click Save.

Configuring the keystoreOut of the box, the MasterCom Claims Manager is configured with the default keystore name. For aproduction setup, update the keystore name with the correct value.

1. In the Designer Studio header search field, enter MCOMClaimsMgrKeystore and, from the searchresults, select the PegaCardSdMasterCard MCOMClaimsMgrKeystore dynamic system setting.

2. In the Value field, type name of the the MasterCom Claims Manager keystore.

3. Click Save.

Configuring the consumer keyUpdate the MasterCom Claims Manager consumer key with one corresponding to the MasterCard projectthat you want to create for your implementation.

1. In the Designer Studio header search field, enter MCOMClaimsMgrConsumerKey and, from the searchresults, select the PegaCardSdMasterCard MCOMClaimsMgrConsumerKey dynamic system setting.

2. In the Value field, type the MasterCom Claims Manager consumer key.

3. Click Save.

Configuring the key aliasUpdate the MasterCom Claims Manager private key alias with one corresponding to the MasterCardproject that you want to create for your implementation.

1. In the Designer Studio header search field, enter KeyAlias and, from the search results, select thePegaCardSdMasterCard MCOMClaimsMgrKeyAlias dynamic system setting.

2. In the Value field, type the MasterCom Claims Manager private key alias.


Delivery stage

3. Click Save.

Toggling simulation modeDepending on whether you want to connect to the Mastercard system, toggle simulation mode on or off.

When simulation mode is enabled, the MasterCom Claims Manager simulates the responses from theMasterCom REST API through simulated data transforms.


2. Perform one of the following actions:

• To enable simulation mode, next to the Enable MCOM Simulation option, click Enable.

• To disable simulation mode, next to the Enable MCOM Simulation option, click Disable.

Configuring simulated data transformsIf you want to simulate REST responses to test the implementation of the MasterCom Claims Manager,configure the simulated data transforms that come bundled with Pega Smart Dispute for Issuers.

Ensure that simulation mode is enabled. See Toggling simulation mode.

For more information about the simulated data transforms that are available with Pega Smart Dispute forIssuers out of the box, see the Simulated data transforms Community page.

1. In the Designer Studio header search field, enter the name of a simulated data transform rule that youwant to review, and, from the search results, select the respective data transform.

2. Click Edit and modify the identifier name.


4. From the Add to ruleset drop-down list, select a ruleset.


6. Review the data transform with the bank.

7. Update the reason code and review all other fields.

Important: For representment, the chargeback type must always be set toSECOND_PRESENTEMENT.

8. Click Save.

Defining custom workbasketsCustomize the DynamicReferenceForWorkbasketExtension data transform to configure newworkbasket names and override existing ones.

1. In the Designer Studio header search field, enter DynamicReferenceForWorkbasketExtension and,from the search results, select the DynamicReferenceForWorkbasketExtension data transform.

2. Click Save as.

3. In the Apply to field, enter the appropriate class name.

4. From the Add to ruleset list, select a ruleset.


6. Configure workbasket names in the DynamicReferenceForWorkbasket value group property.For example: .DynamicReferenceForWorkBasket(Arbitration)


https://community.pega.com/knowledgebase/articles/simulated-data-transforms

Delivery stage

Extending service call request responseCustomize the InvokeMCOMClaimsMgrServiceExtension data transform to configure the handling ofimplementation-specific requirements.

1. In the Designer Studio header search field, enter InvokeMCOMClaimsMgrServiceExtension and,from the search results, select the InvokeMCOMClaimsMgrServiceExtension data transform.

2. Click Save as.




6. In the InvokeMCOMClaimsMgrServiceExtension data transform rule form, add any customfunctionality.

Configuring request post-processingCustomize the MCOMClaimsMgrRequestPostProcessingExtension data transform to configure theMasterCom API request post-processing.

1. In the Designer Studio header search field, enterMCOMClaimsMgrRequestPostProcessingExtension and, from the search results, select theMCOMClaimsMgrRequestPostProcessingExtension data transform.

2. Click Save as.




6. In the MCOMClaimsMgrRequestPostProcessingExtension data transform rule form, add anycustom functionality.

Configuring response post-processingCustomize the MCOMClaimsMgrResponsePostProcessingExtension data transform to configure theMasterCom API response post-processing.

1. In the Designer Studio header search field, enterMCOMClaimsMgrResponsePostProcessingExtension and, from the search results, select theMCOMClaimsMgrResponsePostProcessingExtension data transform.

2. Click Save as.




6. In the MCOMClaimsMgrResponsePostProcessingExtension data transform rule form, add anycustom functionality.


Delivery stage

Configuring documents at the reason code levelThe standard documents required by MasterCard are already preconfigured in out-of-the-box reason coderules. Use the reason code rule form to configure the reason code rules to include any additional andoutbound documents required for your implementation.

1. In the Designer Studio header search field, enter the reason code for which you want to configuredocuments and, from the search results, select the reason code.For example: RC 4853 CC1

2. Click Save as.




6. Select the Documents tab.

7. In the Additional documents section, add an additional document by clicking the Add icon and fill inthe fields.

Note: If the document is required based on specific answers to ancillary questions, you can usethe Condition field to set an appropriate When rule.

8. In the Outbound documents section, add an outbound document by clicking the Add icon and fill inthe fields.

9. Click Save.

Configuring ancillary questions at the reason code levelUse the reason code rule form to configure ancillary question section references and ancillary question-level validations.


2. Click Save as.




6. Select the Details tab.

7. In the Reason Code Details section, configure the appropriate Section Name and AssociatedValidation references.The section rule referenced in the Section Name field contains the ancillary questions that appear onthe “Dispute questionnaire” assignment. The validation rule referenced in the Associated Validationfield validates the answers to those ancillary questions.

8. Click Save.

Configuring dispute validations at the reason code levelUse the reason code rule form to configure the chargeback rights for each reason code as defined in theMasterCard Chargeback Guide.



Delivery stage

2. Click Save as.




6. Select the Details tab.

7. In the Dispute validations section, fill in the configuration fields.

8. Click Save.

Configuring application fraud propertiesYou can manage fraud-related disputes including application fraud.

In an application fraud scenario, the dispute is not just about the transactions that may be fraudulent. Thecustomer is also disputing the existence of the account. They are asserting that they never applied for thisaccount and that someone has opened it for fraudulent purposes.

Do the following tasks to configure application fraud properties.

• Configuring qualify fraud questions

• Configuring the fraud questionnaire

• Configuring the Fraud Case Details data page

• Configuring the investigation outcome subflows

• Configuring the chargeback service level agreement

• Configuring the claim cancellation service level agreement

• Configuring the victim information entry

Configuring qualify fraud questionsQualify fraud questions are presented during the customer fraud interview when a user selects the Checkif claim is Fraud check box on the transaction selection page. Review the questions and add or modifyquestions as appropriate to help the back office with their fraud investigation.

1. In the Designer Studio header search text field, enter QualifyFraudDisputes and select thePegaCard-Sd- section rule from the results.

2. Click Save as.




6. Add or modify questions, if necessary.

Important: Do not modify the question Do you want to continue as Fraud?, as it determines thenext actions in the flow.

7. A dynamic layout exists in this section. Review the sections that appear when the user selectsApplication Fraud from the .FraudTypeApp list.

Important: Do not modify the contents of this list, as this determines which layout ispresented.

8. Click Save.


Delivery stage

Configuring the fraud questionnaireThe Fraud Investigation Questionnaire is shipped with a set of basic questions that a fraud analyst mighthave to answer during the course of investigating a Fraud dispute. Review the questions with the bankand add or modify questions as would be appropriate for how the bank conducts a fraud investigation.

1. In the Designer Studio header search text field, enterCaptureApplicationFraudInvestigationResults and select the PegaCard-Sd-Claim sectionrule from the results.

2. Click Save as.




6. Add or modify questions, if necessary.

Important: Do not modify the question Based on the information gathered, is the analyst ready toproceed with a decision?, as it determines the next actions in the flow.

7. Review the .ApplicationFraudInvestigationResult list contents with the bank to determinewhich outcome flows are called. Modify the rule to suppress any outcomes that are not used by thebank.

8. Click Save.

Configuring the Fraud Case Details data pageThe Fraud Case Details data page is designed to integrate with an interface to an external addressverification system, if a bank wishes to use that functionality.

1. In the Designer Studio header search text field, enter D_FraudulentDetails and select the data pagefrom the results.

2. Click Save as.




6. Click Save.

Configuring the investigation outcome subflowsThe investigation outcome subflows are based on the fraud analyst's decision for an outcome. Theydetermine the actions that follow the analyst's decision.

1. In the Designer Studio header search text field, enter FraudConfirmedCustomerNotLiable andselect the PegaCard-Sd-Claim flow rule from the results.

2. Click Save as.




6. Add any necessary customer-specific procedures to the flows.

7. Determine if correspondence will be created from within Pega Smart Dispute for Issuers or from anexternal correspondence system.


Delivery stage

• If from within Pega Smart Dispute for Issuers, modify the verbiage of each letter within, if necessary.

• If from an external correspondence system, suppress the Pega Smart Dispute for Issuerscorrespondence and create interfaces to the appropriate templates in the customer's externalcorrespondence system.

8. Click Save.

9. Repeat the previous steps for the BankErrorCustomerNotLiable,ValidApplicationCustomerNotLiable, FraudConfirmedCustomerLiable, andProcessSSNForm rules.

Configuring the chargeback service level agreementReview the chargeback service level agreement (SLA) with the bank.

1. In the Designer Studio header search text field, enter ClaimCancellation and select the PegaCard-Sd-Claim service level agreement rule from the results.

2. Click Save as.




6. Review and adjust the goal and deadlines with customer, if necessary.

7. Click Save.

Configuring the claim cancellation service level agreementReview the claim cancellation service level agreement (SLA) with the bank.

1. In the Designer Studio header search text field, enter ClaimCancellation and select the PegaCard-Sd-Claim service level agreement rule from the results.

2. Click Save as.




6. Click Save.

Configuring the victim information entryThe Victim Information section gathers fraud victim info such as name, address, fraud date, and so on.Review the Victim Information section with the bank.

1. In the Designer Studio header search text field, enter ConfirmVictimInformation and select thePegaCard-Sd-Claim section rule from the results.

2. Click Save as.




6. Review the rule with customer and add or modify fields as needed.

7. Click Save.


Delivery stage

Setting up correspondence verificationSet up correspondence rules so that each item of correspondence, defined by a given rule, is routed to themanager’s worklist for verification before it is sent to the recipient.

1. In the Designer Studio header search text field, enter the name of a correspondence letter to whichyou want to apply verification rules, such as AcknowledgeLetter and select the correspondence rulefrom the results.

2. Click Save as.




6. From the After Create list, select Verify.

7. Click Save.

8. Repeat this task for all correspondence letters that need verification.

Modifying automatic correspondenceReview customer-facing correspondence with the bank and determine whether they want to use a Pegasystem or an external system.

Expect to update the content of any correspondence from the bank to the customer, with the bank'sapproved verbiage.

Any forms related to the chargeback lifecycle itself or correspondence with card association (Visa,MasterCard, and so on) does not need to be edited. It is part of the customer's compliance subscription.

1. In the Designer Studio header search text field, enter the name of the correspondence rule that youwant to modify, for example AcknowledgeClaim and select the correspondence rule from the results.

2. Click Save as.




6. Modify the properties or content of the letter, if needed.

7. Click Save.

Modifying automatic correspondence generationPega Smart Dispute for Issuers automatically generates claim correspondence based on conditionsdefined either in an activity or in a flow. The PegaCard-Sd-Claim-.WaitToCloseCover service-levelagreement rule starts the AllCoveredResolvedCheck activity that determines which letters to sendand when to send them. This service-level agreement rule runs every 24 hours until all disputes (coveredobjects) are resolved.

Modify the steps in an activity to stop follow-up letter-sending process. You can change the conditions thatdetermine which letter is sent and its timing.

Claim-level correspondence ( Rule-Obj-Corr ) records are in the PegaCard-Sd-Claim- class.

The following correspondence records are used most often. View each correspondence rule and modifythem, if needed:

1. Modifying the Claim Acknowledgment correspondence


Delivery stage

2. Modifying the Claim Affidavit correspondence

3. Removing the Acknowledgement, Affidavit, and Follow-up letters

4. Modifying the Claim Researching correspondence

5. Modifying the Claim Resolved correspondence

• Modifying the Claim Affidavit correspondence

• Removing the Acknowledgement, Affidavit, and Follow-up letters

• Modifying the Claim Acknowledgment correspondence

• Modifying the Claim Researching correspondence

• Removing the Claim Resolved letter from the flow

Modifying the Claim Affidavit correspondenceA letter is sent if a claim is still in an open status 24 hours after it was created (based on the SLA Deadlinefield), the claim has at least one non-resolved dispute, and the claim reason is fraud. The letter is sent onlyonce, the first time the service level runs.

1. In the Designer Studio header search text field, enter CardHolderAffidavitClaim and select thecorrespondence rule from the results.

2. Click Save as.




6. Click Save as.

Removing the Acknowledgement, Affidavit, and Follow-up lettersThe Acknowledgement, Affidavit, and Follow-Up letters are processed by theSLAOpenCoveredProcessing activity rule. If you remove the first three steps in this activity rule, then theletters are no longer processed automatically.

1. In the Designer Studio header search text field, enter SLAOpenCoveredProcessing and select thePegaCard-Sd-Claim- activity rule from the results.

2. Click Save as.



5. To remove a letter, click that row and then click Delete.

6. Click Save as.

Modifying the Claim Acknowledgment correspondenceA letter is sent if a claim is still in an open status 24 hours after it was created (based on the SLA Deadlinefield) and contains at least one unresolved dispute. The letter is sent only once, when the service levelruns for the first time.

1. In the Designer Studio header search text field, enter AcknowledgeClaim and select thecorrespondence rule from the results.

2. Click Save as.



Delivery stage



6. Click Save as.

Modifying the Claim Researching correspondenceA letter is sent if a claim is still in an open status five days after it was created, and the claim has at leastone unresolved dispute.

1. In the Designer Studio header search text field, enter ResearchingClaim and select thecorrespondence rule from the results.

2. Click Save as.




6. Click Save as.

Removing the Claim Resolved letter from the flowIf you do not want Pega Smart Dispute for Issuers to send the Claim Resolved letter, modify the flow andremove the Resolution Correspondence section.

1. In the Designer Studio header search text field, enter NewWork and select the PegaCard-Sd-Claim- flowfrom the results.

2. Click Save as.



5. Remove the SendResolutionLetter utility shape.

6. Click Save as.

Modifying the OnUs decision mapThe Bank Identification Number (BIN) indicates whether the dispute is an OnUs dispute. If the dispute isan OnUs dispute, then Pega Smart Dispute for Issuers creates an assignment and routes it to the OnUsworkbasket. You may then process according to your business practices.

Use the OnUs decision map to identify your OnUs BIN numbers. If you do not need special processing forOnUs BIN numbers, skip this task.

1. In the Designer Studio header search text field, enter OnUs and select the PegaCard-Sd-Dispute-map value rule from the results.

2. Click Save as.




6. On the Matrix tab, click Configure rows, and then click Insert Row.

7. Enter your BIN numbers and set their values to Y.

8. Click Save.


Delivery stage

Modifying dispute qualification scriptsDispute Qualification scripts contain qualification questions and the TalkOff scripts. Modify the TalkOffflow instance to make changes to the questions or the scripts. You can also add new questions.

1. In the Designer Studio header search text field, enter ActionInvokeTalkOff and select thePegaCard-Sd-Dispute-section rule from the results.

2. Click Save as.




6. Modify or move the questions as necessary.

Note: You can modify or add questions. Do not remove questions.

7. Click Save.

Setting up duplicate scoring rulesPega Smart Dispute for Issuers can flag transactions as duplicates based on scoring rules that considerdata elements such as the transaction amount, transaction date, account number, and acquirer referencenumber. Pega Smart Dispute for Issuers can also accept close matches, for example, two items datedwithin three business or calendar days. You can also weight the two conditions so that an amount matchis twice as important as a date match.

When a dispute is entered, Pega Smart Dispute for Issuers uses the Duplicate search to locate possibleduplicates. The Rule-Search-Scoring rule identifies the critical fields for locating potential duplicates.For each identified field, you set the conditions and a weighted average to be used when searching forduplicates. Pega Smart Dispute for Issuers tallies a score (weighted average) based on each matchingfield value and marks the case for review if the score exceeds the defined number. You can also set athreshold, which if not met, allows the case to continue through normal processing.

1. In the Designer Studio header search text field, enter DuplicateScore and select the PegaCard-Sd-Dispute-scoring rule from the results.

2. Click Save as.




6. To change the comparison operation, select a value from the selection box.

Exact Match A string comparison; values (such asamounts, dates, or text) must match exactly.

Range A numeric comparison; values (such asamounts) must match within a certain range.

Range in Days (C) For a date match, the range in calendar days.

Range in Days (B) For a date match, the range in business days,using a calendar to determine valid businessdays.

7. Enter new values in the Lower Bound and Upper Bound fields. For operations other than Exact Match,use values relative to the value of the case being searched. Enter ranges as –x to y. For example, for


Delivery stage

a range of -1 to 1, a match occurs if the potential case has a value ± $1 from the amount of the casebeing searched.

8. Enter a value in the Weight field. The Weight values are arbitrary, but must add up to 100 percentage.

9. To change the Minimum Confidence Threshold, enter a number from 1 to 100. For example, in the ruleabove, the weighted average of the four conditions is 100. If you set the threshold to 75, the systemautomatically identifies the case as a duplicate and continues processing when three conditions aremet.To add a new comparison, click Add Row. Make sure any properties you add are valid and that youadjust the weighting correctly. To delete a comparison, click Delete Row.

10. Click Save.

Modifying multiple partial dispute valuesThis feature restricts the processing of multiple partial disputes on the same transaction if the totalexceeds the transaction amount. The system ensures that the sum of all the disputes which have beenresolved in the cardholder’s favor and disputes in progress do not exceed the transaction amount itself.The IsInCustomerFavor rule lists the statuses that are considered resolved in the customer's favor.Update this rule to add or change this status list.

1. In the Designer Studio header search text field, enter IsInCustomerFavor and select the Work- whenrule from the results.

2. Click Save as.




6. Add or remove values, if needed.

7. Click Save.

Configuring reassertion valuesReassertion is the process in which a customer wants to reopen a previously closed and denied claim. Forreassertion, instead of reopening the old dispute (which may violate the regulation dates), a new disputeis created.

1. In the Designer Studio header search text field, enter ValidReassert and select the PegaCard-Sd-Dispute class when rule from the results.

2. Click Save as.




6. Add or edit values, if needed.

7. Click Save.

8. Repeat steps 2-7 for the ReassertNotResolved when rule, if necessary.

9. Repeat steps 2-7 for the CalculateReassertionDates activity rule, if necessary.


Delivery stage

Defining new bank identification numbersIf you add new banks as parties to the association, you need to define new bank identification numbers(BINs). One bank may require multiple BINs. BINs are defined in the BINnnnnnn Model rule (an instance ofRule-Obj-Model), where nnnnnn is the issuer number.

1. In the Designer Studio header search text field, enter BIN435237 and select the PegaCard-Party-Bankdata transform rule from the results.

2. Click Save as.

3. Click Edit to edit the Identifier name and enter a new BIN name.



6. Edit the list of properties as necessary to define the new issuer.

7. Click Save.

Configuring approval flowsPega Smart Dispute for Issuers provides default approval flows that serve as reusable assets which can beadded to a process. These default flows include write-off, pre-compliance, and arbitration approval flows.

1. In Designer Studio, click Launch > Disputes Manager portal.

2. Click Configuration wizard.

3. Expand each approval flow and decide whether or not they should be enabled.

4. If the approval flow is enabled, ensure that the threshold amount is correct for each value.

5. Click Add item to add thresholds, if necessary.

Working with accounting functionsThe tasks in this section describe how to configure the Pega Smart Dispute for Issuers accountingfunctions.

• Setting up account step rules

• Defining the chart of accounts

• Setting up account types

• Setting up payment types

• Setting up verification levels

• Setting up cutoff times

• Setting up suspense accounting

• Cut-off times and the calendar

• Configuring automatic chargeback

Setting up account step rulesThe accounting automatic flows and flow actions use a specific action of a rule class, such as OpenPayable (Open action of the Payable rule) or Adjustment (Adjust action of the Adjustment rule). Smart


Delivery stage

Dispute supports Adjust and WriteOff adjustment actions and Open, Close, Lower, and WriteOff suspenseactions.

Automatic flows require a parameter specifying the appropriate rule to use. The parameter specifies theType property and the flow determines the other key parts (RuleClass, action, and work object class).Manual flow actions can also determine these key parts and display Short Descriptions from everystep rule that the flow action can use, including security validation. By default, Smart Dispute uses thetransaction information from the rule with the highest likelihood and lets you select any other valid steprules from a list of rules and their short descriptions.

Use the account step rule decisions you made during the planning topic, Defining accounting step rules.

1. In the Application Explorer, search for the Rule-PegaAcct-Financial-Adjustment, Rule-PegaAcct-Financial-Payable, or Rule-PegaAcct-Financial-Receivable class, and select arule to edit, such as WriteOffCrCardHolder.

2. Click Save as.




6. On the Transactions tab, edit values for DR / CR, Label, Pymt Type, and so on, if necessary.

7. Click Save.

See Fields on the Adjustment Rule form for more information.

• Fields on the Adjustment Rule form

Fields on the Adjustment Rule formThe following table describes the fields in the Adjustment Rule form.

Field Description

Short Description Required. Short description of the rule. This value is displayedduring manual accounting in the list of step rules the user canselect.

Step Tab

Class of the Step The class of the page that holds the Step data. Specify a Rule-Obj-class name that is a concrete class and is a child of thePegaAcct-Step- class.

Activity for Verification Flow An activity at the class of the step that calls a verification flow. Ifblank, the system automatically passes the accounting throughwithout verification. One activity delivered with the productspecifies a verification flow based on amount values. The activitylets you do verification up to four levels, which can be usedbased on the amount of the step.

Model to create Step A Rule-Obj-Model rule name at the class of the step. If specified,the system creates the step page based on the model. The steprules in the product do not use a model.

Validate Activity Reserved for future use.

Likelihood An integer between 0 and 100 that is used to preselect the mostlikely step rule (the one with the highest number) during themanual flow actions that create accounting steps.

Transactions Tab


Delivery stage

Field Description

Group Specifies whether this accounting transaction is part of a groupof transactions such that only one transaction in the group isused when the accounting is created. In manual processing, theuser chooses a transaction from the group (the Label propertyis displayed in a selection box so that only one transaction canbe chosen). In automatic processing, the first transaction inthe group is selected automatically so the transaction order issignificant.

Note that Smart Dispute does not use groups because there is asingle internal account for Receivable, Write-Off, and so on.

Label Appears in the window during manual accounting creation flowactions to indicate the name of the transaction.

DR / CR Indicates whether the transaction is a Debit or a Credit. The rulerequires that debits are listed before credits for consistency. Theorder of the transactions in the rule is the order in which theyare displayed during manual accounting creation flow actions.

Role A unique string identifier for each transaction in this step. Itsvalue is placed into a property named Role in the transaction ofthe step, and can be used to find or report on the transaction.

Txn Class The class of the page that holds the transaction data. Select aRule-Obj-Class name that is a concrete child class of PegaAcct-Txn-.

Pymt Type Name of the Rule-PegaAcct-Financial-PaymentType rule touse for this transaction. The payment type rule associatescorrespondence with the transaction.

Default Account From Specifies how to determine the account name and number forthis transaction:

• Party: Take from the Party role in the work object. (The roleis specified in the DefaultAccountValue property.)

• Chart of Accounts: Take from a specified internal account.The value of the DefaultAccountValue property is used ina lookup to a Map Value named FinChartOfAccts at theclass of the work object. This process returns a key to aData Party record. A second Map Value is used at the classof the work object to determine the actual party class inwhich to look up this key. The system finds the party classby looking up the InternalAccount value in the Map Valuenamed WorkPoolClasses.

Account From Value Specifies a party role if the Default Account From value is Party.Specifies an internal account name (as defined in the map valueFinChartOfAccts) if the Default Account From value is Chart ofAccounts.

Protect Account? Select to prevent input in the Account Name and Number fieldsof the user interface during manual accounting creation. Ifnot selected, users can modify these values during manualaccounting creation.

Default Amount From Specifies where to acquire the amount value for this transaction:

• Property: use the property value specified in theDefaultAmountValue property.

• Literal: use the value of the DefaultAmountValue property.


Delivery stage

Field Description

Amount From Value Specifies a property reference if DefaultAmountFrom isProperty. A reference can be any fully qualified propertyreference from any page. If the property reference is not dotqualified, then Smart Dispute assumes that the property is onthe top level of the work object page.

Specifies an actual amount number value if Default AmountFrom is Literal. Do not use quotation marks, $, or commas (forexample, if the value is one thousand, enter 1000.00 and notany of the following: $1,000.00 or $1000.00 or "1000.00").

Protect Amount? Select this check box to prevent input in the Amount field ofthe user interface during manual accounting creation. If notselected, users can modify this value during manual accountingcreation.

Security Tab

Name Optional. Enter the name(s) of any named privileges whereaccess to the privilege allows this step to be executed.

Class Optional. Enter the class of privileges you specify in this window.

When Name Optional. Enter a Rule-Obj-When rule that equal true for thisstep to be executed. Most Smart Dispute step rules use Whenrules to allow step access only if the referenced Party Role existsin the work object.

History Tab Full description of the adjustment rule and information on itsusage.

Defining the chart of accountsUse the chart of accounts to specify general-ledger accounts that are associated with internal accountswithin the product. You can set up a chart of accounts that refers to the internal accounts of yourorganization. General-ledger accounts are added in the Setting up account types task.

The Account column lists the codes referenced in the Rule-PegaAcct-Financial-Payable, Rule-PegaAcct-Financial-Receivable, and Rule-PegaAcct-Financial-Adjustment step rules. Do notchange these values unless you have overridden all step rules that refer to them.

1. In the Designer Studio header search text field, enter FinChartofAccts and select the PegaCard-Sd-Dispute class map value rule from the results.

2. Click Save as.




6. Configure the accounts in the chart.

Note: The Bank Number column shows the keys of internal accounts if you are running in amulti-bank environment. You can have multiple banks with multiple accounts.

7. Click Save.


Delivery stage

Setting up account typesPega Smart Dispute for Issuers uses internal accounts to track accounting transactions. Internal accountsare defined in the PegaAcct-Party-InternalAccount class. Internal accounts are referenced in thechart of accounts.

1. In the Application Explorer, search for the PegaAcct-Party-InternalAccount class, and select theVisaClearing rule to use as a template for a new account type.

2. Click Save as.




6. Enter values for the new account.

7. Click Save.

Setting up payment typesPayment types are associated with a debit or credit transaction in an accounting step. They can determinethe following:

• Whether documents or automatic advices are generated.

• Whether an accounting cutoff time is enforced.

The payment type is associated with a transaction in step rules. If your organization’s transactions requiredocuments different than the ones referenced in the supplied payment-type rules, or if you requiredifferent cutoff times, then create the Rule-Obj-Corr and Rule-PegaAcct-Financial-Cutoffrules first, and then copy the payment-type rule with the same name to your ruleset. If you require newpayment types, create your own by copying and updating an existing one, and then updating the steprules to reference the new payment types.

The stream name, correspondence type, and the class represent the key to the correspondence rule.When you define the payment type rule, you indicate which correspondence rule to use by specifying twoof the key properties (Stream Name and Corr Type), to which the system implicitly adds the work objectclass.

1. In the Application Explorer, search for the Rule-PegaAcct-Financial-PaymentType and select anexisting payment type rule to use as a template for a new payment type.

2. Click Save as.




6. Configure the accounts in the chart.

7. Select the Document Required check box to generate a document for all transactions that use thispayment type.

Note: If you do not select this check box, the document is not generated for automaticprocessing, but you have the option to generate it during manual processing.

8. Click Save.


Delivery stage

Setting up verification levelsYour organization can have a policy stating that adjustments above a certain amount must be verified bya manager. For example, you can choose not to require verification for credits below $100, but require asenior review and verification for accounting credits of more than $5,000.

By default, no accounting steps require verification; however, you can configure up to three levels ofverification based on value. The verification levels are the number of times an item is verified. Theprivileges assigned to users determine the top level at which a user can verify. A user can only verify anaccounting step once, regardless of their privileges.

To include verification in your business flows, you must configure step rules to specify a value ofFinVerifyByAmount in the Activity for Verification Flow field on the Step tab. This activity uses theFinVerificationFlowByAmount map value, in the PegaAcct-Step class, to determine the verificationlevels based on the amount thresholds. If you review these values and find them suitable for yourorganization, you can use the rule as is.

1. In the Designer Studio header search text field, enter FinVerificationFlowByAmount and select thePegaAcct-Step class map value rule from the results.

2. Click Save as.




6. Configure the verification levels, if needed.

7. Click Save.

Setting up cutoff timesYour organization can define the time of day after which completed transactions must be posted to thenext business day. A cutoff rule named Default, defined by the Rule-PegaAcct-Financial-Cutoffrule, uses a warning time and a cutoff time. The rule ensures that business hours are not included in thecutoff time.

If your organization requires different cutoff times for different payment types, create new cutoff rules inyour ruleset and update your Rule-PegaAcct-Financial-PaymentType rules to reference them. Anynumber of payment types can refer to the same cutoff rule.

For example, if your card processing system has a settlement deadline, then the Rule-PegaAcct-Financial-Cutoff rule can define the cutoff times. Each payment type sent to the card processingsystem for settlement can reference the Settlement cutoff rule in the Rule-PegaAcct-Financial-PaymentType rule. When a deadline or processing window changes, you can update the Settlementrule. All payment types referencing the Settlement rule automatically become a subject to the new cutoffschedule.

The warning and cutoff times in the rule affect only the user interface. When processing an accountingstep that has not yet been posted (at creation, verification, or held in cutoff), you see a yellow clock iconnext to any transaction that is past its warning time and a red clock next to any transaction that is past itscutoff time.

1. In the Application Explorer, search for the Rule-PegaAcct-Financial-Cutoff class, and select theDefault rule to use as a template for a new account type.

2. Click Save as.





Delivery stage

6. Configure the cutoff times.

7. Click Save.

8. In the PegaAcct-Financial-PaymentType class, associate the new cutoff times with the paymenttype rules.

Setting up suspense accountingBy default, Pega Smart Dispute for Issuers splits the sum total of an open suspense transaction betweenthe Outstanding and Suspense Balance of the work item on pyWorkPage.

For example, if an Open step contains the following:

• Debit Suspense Receivable 150/USD

• Debit Fee Reversal 35/USD

• Credit Customer Account 185/USD

Then the Suspense and Outstanding balance would be written as 185/USD.

This is done to avoid writing off the 35/USD fee reversal, and it assumes full recovery of the 150/USDreceivable. This approach may result in two separate credits to the customer. You can optionally createone accounting step that correctly accounts for the suspense balances and provides a single credit to thecustomer.

Performing a raise action on a suspense entry increases the balance amount that is applied to thesuspense general ledger. Performing lower, close, or write-off actions reduces this balance, eventually to0/USD.

1. In the Designer Studio header search text field, enter UseNewSuspenseAccounting and select thewhen rule from the results.

2. Click Save as.




6. Set the values to true for the account.

7. Click Save.

Cut-off times and the calendarBefore a step can be posted during accounting cutoff processing, all transactions in the step are checkedagainst the cutoff time in the Rule-PegaAcct-Financial-Cutoff class specified by the Rule-PegaAcct-Financial-PaymentType rule. Depending on the type of transaction, the Rule-PegaAcct-Financial-PaymentType rule specified in one of the following step rules is checked:

• Rule-PegaAcct-Financial-Adjustment

• Rule-PegaAcct-Financial-Payable

• Rule-PegaAcct-Financial-Receivable

Before using the specified cutoff time, the system checks the calendar to check whether the processingoccurs on a business day. If it is not a business day, the transaction is automatically held for cutoff andposted on the next business day. The steps held for posting on the next business day are re-releasedfor posting at the time specified in the FinReleaseTime activity in the Rule-PegaAcct-Financial-Cutoff class. The steps can also be released by users with sufficient security privileges.


Delivery stage

The Default calendar, used in all areas of the product, is specified in the FinCutoffCalendar map valuerule in the Rule-PegaAcct-Financial-Cutoff class. You can create an additional calendar if yourorganization requires a separate calendar specifically for accounting cutoff days.

Note: It is important to verify the dates and times in your calendar. If the system encounters adate not found in any calendar instance, it assumes that the date is a non-business day.

• Setting up calendars

Setting up calendarsPega Smart Dispute for Issuers uses calendars to determine which dates are business days as well as thehours of operations on those days. Non-business days include weekends and holidays. Calendars affectthe following activities:

• Service level rules can specify goal and deadline times in business days

• Accounting can only be posted on business days

1. In the Application Explorer, search for the Data-Admin-Calendar and select a calendar namedDefault.

2. Click Save as.




6. Adjust the business hours or add holidays, if necessary.

Important: Calendars are stored as instances of the Data-Admin-Calendar class. Calendarsmust be named Default and use a start date of January 1 in the format yyyymmdd. Update orcreate instances for each year to define business days and local holidays.

7. Click Save.

Configuring automatic chargebackWhen the rules determine that qualifications have been met for chargeback, Smart Dispute determinesif an automatic chargeback should be initiated. The DetermineAutomation activity enables you to togglebetween manual and automatic.

1. In the Designer Studio header search text field, enter DetermineAutomation and select thePegaCard-Sd-Dispute- activity rule from the results.

2. Click Save as.




6. Set chargeback to true, if needed.

7. Click Save.

Integrating dataYou can integrate your database tables using a data page that calls a report definition. The results appearin a data page (each record is an instance of a data class).

To integrate data into a Pega Smart Dispute for Issuers application:


Delivery stage

1. Replace Pega Foundation for Financial Services integration layer with your own integration classes toconnect to your external data. This could be using a connector to a web service or the Database TableClass Mapping wizard for a database.

2. Create a report definition in the new integration layer.

3. Create a data class based on the Pega Foundation for Financial Services data class and PegaFS-Dataas per your requirement.

4. The report definition can be used in a data page. The data page can also use a connector to a webservice or use a Lookup to fetch details from the external database table.

5. Create the data transforms OpenMap and SaveMap for newly created integration class for fetchingthe data from the table and saving the data into the table. The property names for columns from thedatabase should be mapped to the Pega Foundation for Financial Services properties, if the data layerof Pega Foundation for Financial Services is intended to be reused. Modify the response data transformfor the data page.

6. Repeat this process to populate all of the data pages that need to fetch data from the data layer.

Here is an example of how to obtain credit card account data from an external database for an applicationnamed MyApp.

1. Use the Database Table Class Mapping wizard to generate a data class named MyApp-Int-SAMPLE_CCACCT that accesses the external database table with credit card account information.

2. Create a report definition named GetCreditCardDetails that returns a list of all the credit card accounts.

3. Create data transforms OpenMap and SaveMap in MyApp-Int-SAMPLE_CCACCT.

4. Create a data page D_MyAppCreditCardAccountDetails data pages (for example,D_CreditCardAccountSummary) to use the report definition that you created.

5. Create a response data transform in the Code-Pega-List class which uses the OpenMap data transformto fetch data from the database table.

Configuring integration componentsPega Smart Dispute for Issuers has several flows that enable you to configure external components,including a self-service portal as well as Verifi and VSOL components.

• Configuring self service and CSR flows

• Configuring CSR reason codes

• Enabling the third-party resolution network

• Enabling specific third party resolution networks


https://pdn.pega.com/sites/pdn.pega.com/files/help_v73/procomhelpmain.htm#rule-/rule-obj-/rule-obj-report-/rule-obj-report-definition/main.htm

Delivery stage

• Setting the third-party resolution preference

• Configuring Verifi integration

• Configuring Ethoca integration

• Configuring VROL integration

Configuring self service and CSR flowsPega Smart Dispute for Issuers contains alternative flows that are more appropriate to expose to a bank'sonline banking portal or Customer Service desktop. The U+Financial portal included with the FSIF layerprovides a sample implementation of these flows.

The main flow for Self Service cases is BeginSingleDisputeTransactionSearch where theCommunication Source will be defaulted to "Self Service."

The main flow for CSR-initiated disputes is BeginSingleDisputeTransactionSearch which internallycalls another flow BeginSingleDisputeTransactionSearchCSR.

Review each flow with the bank and modify them, if needed.

1. In the Designer Studio header search text field, enter BeginSingleDisputeTransactionSearch andselect the flow rule from the results.

2. Click Save as.




6. Modify the flows, if needed.

7. Click Save.

8. Repeat the previous steps for BeginSingleDisputeTransactionSearchCSR, if needed.

Configuring CSR reason codesThe SSSuggestReasonCode decision table determines the likely reason code based on the association(Visa, Master Card, Amex) and the dispute reason chosen. You can update the reason codes in thedecision table.

1. In the Designer Studio header search text field, enter SSSuggestReasonCode and select thePegaCard-Sd-Dispute decision table from the results.

2. Click Save as.




6. Modify the reason codes, if needed.

7. Click Save.

Note: Back office users in the DisputeOperator access group will be able to access the Customer-initiated workbasket. Note that the suggested reason code, per the rule SSSuggestReasonCode,appears in the action area of the harness It allows the user to invoke Reason Code Advisorto confirm the suggested reason code, or, if they have sufficient privilege, select the ReasonCode directly from the drop-down list, then continue to Ancillary Questions and chargeback. Inorder to see the CustomerClaim/Fraud workbaskets, the back office user should be set up asDisputeOperator.


Delivery stage

Enabling the third-party resolution networkEnable the third-party resolution network in order to integrate with third-party resolution networks.This primary setting validates whether the third-party network is available for disputes processing. Thedynamic system settings can be accessed through the configuration panel in Designer Studio.

Before beginning this process, confirm that the customer has agreements in place with the networkthey wish to implement. The agreement is between the customer and the respective network, notbetween Pega and the network. If the customer does not have agreements in place and wishes to use thisfunctionality, direct the customer to contact Verifi and/or Ethoca directly.

1. Click Designer Studio > Smart Dispute Configurations > Third Party Resolution Network .

2. On the Third Party Resolution Network Panel tab click the Enable button for Third party disputeresolution network.

Enabling specific third party resolution networksThe DetermineThirdPartyResNetwork decision rule lists the third party network names and is createdto evaluate the network name and its respective data class. Set the value to true along with the specificresolution network name to invoke that particular system.


2. On the Third Party Resolution Network Panel tab click Determine Third Party Network.

3. Update the decision table either to true or false based on the third party system integration to returnthe Integrated System Name. This table can be extended to add new third-party networks in the future.

Note: Setting all the conditions to false disables all the third party networks during the disputeprocess.

Setting the third-party resolution preferenceIf multiple networks are enabled, you can configure Pega Smart Dispute for Issuers to evaluate thepreferred third-party network for merchant eligibility by evaluating the parameters configured. Use theRankThirdPartyNetwork to specify the order of preferred third-party networks. Additionally, you canconfigure the application to consider other transactional data values to determine which network shouldbe used if the transaction data meets specific criteria.

For example, the bank may want to route disputes to one of the third-party networks based on aparticular POSEntrymode value.

If the POSEntrymode value of the disputed transaction matches that value, then the applicable networkis the first preference for routing the dispute. The application checks the merchant list to see if themerchant subscribes to that network. If so, the application routes the dispute to the preferred network forprocessing. If the merchant does not subscribe to the preferred network, the application then selects thenetwork with the next best rank and checks for merchant eligibility.

1. In Designer Studio, in the Data explorer, click Third Party configurations.

2. On the Records tab, review the ranking and parameters of the third-party networks and add applicablevalues for TerminalCode and POSEntryMode to determine which third-party network to use first.

Configuring Verifi integrationPega Smart Dispute for Issuers integrates with the Verifi chargeback management program.

For more information on Verifi case logic, see Verifi case creation logic.

Use the following steps to configure Verifi.

• Configuring the end point URL for the Verifi Resolution Network


https://pdn.pega.com/verifi-case-creation-logic/verifi-case-creation-logic

Delivery stage

• Configuring merchant filter criteria

• Configuring the Verifi merchant eligibility criteria

• Configuring the Verifi merchant list retrieval logic

• Configuring the Verifi merchant list service file primary class

• Configuring the Verifi reason codes

Configuring the end point URL for the Verifi Resolution NetworkYou must configure the end point URL for the Verifi Resolution Network in order to integrate with Verifi.


2. On the Verifi Integration Settings tab, in the End Point URL field, enter the URL.

3. Click Update URL.

Configuring merchant filter criteriaThe DetermineMerchantFilterCriteria activity contains the matching logic suggested by Verifi. Youmay need to update or extend this rule for your particular merchant data.

1. In the Designer Studio header search text field, enter DetermineMerchantFilterCriteria andselect the Verifi activity rule.

2. Click Save as.




6. Edit the merchant criteria, if necessary.

7. Click Save.

Configuring the Verifi merchant eligibility criteriaThe DetermineMerchantEligibilityCriteria rule contains merchant eligibility criteria. You mayneed to update or extend this rule for your particular merchant data.

1. In the Designer Studio header search text field, enter BrowseVerifiMerchantList and select theVerifi activity rule.

2. Click Save as.




6. Edit the merchant eligibility criteria, if necessary.

Note: Update the BrowseVerifiMerchantList report definition to customize the merchanteligibility criteria.

7. Click Save.

Configuring the Verifi merchant list retrieval logicThe service file rule ReadVerifiMerchantList will be triggered based on the interval given. The servicerule will clean up the current merchant list table, and update it with the data that is retrieved from the


Delivery stage

Verifi merchant list files. Below are the rules used for merchant list retrieval. Merchant list retrievalhappens on the Read and Delete activities.

1. In Designer Studio click Records > Integration-Resources > File Listener and open theReadVerifiMerchantList listener.

2. Click Save as.




6. Edit the listener node IDs, if necessary.

7. Click Save.

Configuring the Verifi merchant list service file primary classBy default the primary class for the merchant list service file is PegaCard-Interface-ThirdParty-Verifi-MerchantList. If you need to change this, follow these steps:

1. In the Designer Studio header search text field, enter ReadVerifiMerchantListServiceFile andselect the Verifi service file rule.

2. Click Save as.




6. Edit the primary page class, if necessary.

7. Click Save.

Configuring the Verifi reason codesThe ValidateReasonCodeEligibility decision table lists the Verifi reason codes, and maps theassociation-standard codes in Pega Smart Dispute for Issuers to that list. For example, Master Card RC4802 needs to be passed to Verifi as 2.

1. In the Designer Studio header search text field, enter ValidateReasonCodeEligibility and selecta decision table rule for the type of account you want to view, for example, Master Card.

2. Click Save as.




6. Review the default reason codes and add any, if necessary.

7. Click Save.

8. Repeat the previous steps for the other types of accounts.

Configuring Ethoca integrationPega Smart Dispute for Issuers integrates with the Ethoca chargeback management program. Use thefollowing steps to configure Ethoca.

• Configuring the end point URL for the Ethoca Resolution Network

• Configuring Ethoca merchant filter criteria


Delivery stage

• Configuring Ethoca merchant eligibility criteria

• Configuring Ethoca merchant list retrieval logic

• Configuring Ethoca auto-closure threshold amounts

Configuring the end point URL for the Ethoca Resolution NetworkYou must configure the end point URL for the Ethoca chargeback management program in order tointegrate with Ethoca.


2. On the Ethoca Integration Settings tab, in the End Point URL field, enter the URL.

3. Click Update URL.

4. If not enabled, enable the Enable Ethoca Merchant Lookup API. Enabling this API enables the systemto retrieve merchant eligibility information in real time.

5. If not enabled, enable the Enable Callback Feature. The callback service enables the system to receivenotifications from Ethoca for alert IDs and merchant outcome processing.

Configuring Ethoca merchant filter criteriaThe DetermineMerchantFilterCriteria activity contains the matching logic suggested by Ethoca. Youmay need to update or extend this rule for your particular merchant data.

1. In the Designer Studio header search text field, enter DetermineMerchantFilterCriteria andselect the Ethoca activity rule.

2. Click Save as.




6. Edit the merchant criteria, if necessary.

7. Click Save.

Configuring Ethoca merchant eligibility criteriaThe DetermineMerchantEligibilityCriteria rule contains merchant eligibility criteria. You mayneed to update or extend this rule for your particular merchant data.

1. In the Designer Studio header search text field, enter BrowseVerifiMerchantList and select theEthoca activity rule.

2. Click Save as.




6. Edit the merchant eligibility criteria, if necessary.

Note: Update the BrowseVerifiMerchantList report definition to customize the merchanteligibility criteria

7. Click Save.


Delivery stage

Configuring Ethoca merchant list retrieval logicThe service file rule ReadEthocaMerchantList will be triggered based on the interval given. The servicerule will clean up the current merchant list table and update it with the data that is retrieved from Ethocamerchant list files. Below are the rules used for the merchant list retrieval. Merchant list retrieval happenson the Read and Delete activities.

1. In Designer Studio click Records > Integration-Resources > File Listener and open theReadEthocaMerchantList listener.

2. Click Save as.




6. Edit the listener node IDs, if necessary.

7. Click Save.

Configuring Ethoca auto-closure threshold amountsWhen a dispute is resolved by the merchant and the merchant outcome is Resolved, with the refund flagas Not Refunded or NULL, the application checks if the dispute amount is greater than the thresholdamount configured. If yes, the application routes the dispute to a separate workbasket so that the CSRcan contact the cardholder to verify. If the dispute amount is at or under the threshold, the applicationautomatically resolves the dispute with a correspondence sent to the cardholder.

If the issuers decide to disable the auto-closure feature, the threshold amount can be configured as 0 sothat all disputes are routed to a workbasket for contacting the cardholder.

1. From the Disputes Manager Portal, click Configuration Wizard.

2. Expand the Ethoca Threshold Configurations section and enter or modify thresholds based oncustomer’s business requirements, if necessary.

Configuring VROL integrationPega Smart Dispute for Issuers ships with data mapping rules to help issuers integrate the applicationto Visa Resolve Online (VROL), Visa’s dispute processing solution. The data mapping rules map the PegaSmart Dispute for Issuers properties with the VROL attributes, to reduce the analysis effort.

All the VROL Integration classes and the respective VROL properties have been created in thePegaCard-Int ruleset. You will need to build your own classes for VROL integration. See theSmartDispute_VROLMapping.xlsx file on the Smart Dispute for Issuers product page.

Testing a new applicationTesting a new application includes the following procedures:

• Testing your application in the Build environment

• Testing in the Test or Production environments

• Testing in the UAT environment


https://pdn.pega.com/products/smart-dispute-issuers

Delivery stage

Testing your application in the Build environmentTest a new application in the Build environment before migrating the new application to a Test orProduction environment. Testing in the Build environment enables you to verify that basic functionalityand interfaces work correctly and also that performance is acceptable.

1. Run functional tests to test specific features from the end-user perspective.

2. Use the Performance tool to measure the performance of the application. For information about thePerformance tool, see About the Performance tool.

• Prior to extending your site-specific Pega implementation, establish a performance benchmark(baseline) using the Performance tool. This allows subsequent, iterative performance testsagainst the established baseline to help identify any degradation in performance resulting fromdevelopment efforts.

• Use the Performance tool to check the performance of the following features:

• Search

• Account selection

• Loading of components

• Kickoff of all service intents. For this unit testing, automated scripts are recommended but notrequired.

• Save the test results so that you can compare them to future test results to determine whether anapplication update has a performance impact.

3. Verify that the Pega-provided reports and your custom reports run successfully, and that they showyour implementation layer data, rather than the default demonstration data. This can be an automatedtest.

4. Test all integrations, both independently and with associated integrations.

Test integrations for any optional Pega Smart Dispute for Issuers components and other applicationsthat you plan to use. See the product documentation for the component or application to determinewhich product components to test.

5. Test security. Test the most common roles to ensure that the required access groups are configuredand point to the correct software version.

Testing in the Test or Production environmentsAfter you import the application to a Test or Production environment, test the application in the newenvironment to verify that it works correctly in that environment.

Note: For a multitenancy configuration, run tests in each tenant region. The testing performed inthe Test environment should include usability testing to ensure that the application meets the UIstandard.

1. Verify that the source and the destination files are the same.

2. Run functional tests to test specific features from the end-user perspective.

3. In the Test or Production environment, run the Application Guardrails Compliance Score to ensure thatthe application meets guardrails.

4. Verify that the Pega-provided reports and your custom reports run successfully, and that they showyour implementation layer data, rather than the default demonstration data. This can be an automatedtest.

5. Test all integrations, both independently and with associated integrations.


https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#tools/performance/aboutperformancetool.htm

Delivery stage

Test integrations for any optional Pega Smart Dispute for Issuers components and other applicationsthat you plan to use. See the product documentation for the component or application to determinewhich product components to test.

6. Verify that the integrations point to the correct system of record, and not to the system of record forthe Build environment.

7. Test security. Test the most common roles to ensure that the required access groups are configuredand point to the correct software version. Use these common roles in your smoke tests (see next step).

8. Run a smoke test to compare the source and destination environments. Verify that all tests that passin the Build environment also pass in the Test or Production environment. If anything fails, comparethe environments to determine whether a difference in environment could cause the test to fail. Ifthe environment caused the failure, either fix the issue that caused the failure or adjust the test asappropriate for the new environment.

9. Run performance tests to verify that performance meets expectations. Pega recommends automatedperformance testing. Save the results so that you can compare them to future performance test resultsto determine whether an application update has a performance impact.

Testing in the UAT environmentAfter you complete testing in a Test environment, it is common to perform User Acceptance Testing (UAT)in a designated UAT environment, which could be a pre-production environment. UAT ensures that endusers will be able to successfully complete work and meet business objectives.

Note: Organizations that use Scrum for application development will complete less formal UAT aspart of each sprint cycle.

1. Verify the integrity of the UAT environment.

2. Have the end-users (or business analysts acting the role of end-users) run scripts to test all scenariosincluding boundary and exception testing. The end-users (that is, the trainers, managers, anddirectors), perform the following steps during UAT:

a) Verify that there are no major issues.

b) Review changes in order to better understand the features.

Packaging a new applicationTo migrate a new application to a different environment, you must first package the application so that itcan be imported to the new environment.

Packaging and importing a new application includes the following procedures:

• Merging application changes

• Packaging an application for migration

• Importing the packaged application

Merging application changesIf you developed your application features in separate branches, use the Merge Branches wizard to mergethe branches before you package the application. The wizard shows any merge conflicts so that you cancorrect them before you merge the branches.

For more information about using Merge Branches wizard, see Branch development.


https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#designer-studio/merging/ds-branch-development-and-merging-con.htm

Packaging an application for migrationBefore you can migrate a new application to a different environment, you must package the relevant datainstances and rulesets into a product rule. The product rule is an instance of Rule-Admin-Product, andit is referred to as the RAP file.

1. Click Designer Studio > Application > Distribution > Package to start the Application Packagingwizard. For information about using the wizard, see Application Packaging wizard.

2. Complete each page of the Application Packaging wizard.

3. On the last page of the wizard, click Preview.

4. Review the contents of the generated RAP file.

5. On the last page of the wizard, click Modify to make any changes.

6. When the RAP file is complete, click Export. The wizard creates a .ZIP file in the ServiceExportdirectory on the current application server node.

Importing the packaged applicationTo deploy a new application to a different environment, import the .ZIP file that contains the packagedapplication to the new environment.

1. Click Designer Studio > Application > Distribution > Import.

2. Use the Import Gadget to import the target .ZIP file. For more information, see Import wizard landingpage.

For information about how to swap the database connection pointers to your Production database afteran import to a Production environment, see the Pega Platform Upgrade Guide at Deployment Guides.

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#tools/applicationpackage/sm-app-pack-wizard-con.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#tools/moverules/moverules4.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#tools/moverules/moverules4.htm

https://pdn.pega.com/support-resources/deployment-upgrades/deployment-guides

Production maintenance and monitoring

Production maintenance and monitoringProduction maintenance and monitoring includes the following procedures:

• Business rule maintenance in the Production environment

• Application health monitoring

• Identifying and reporting issues

Business rule maintenance in the ProductionenvironmentAs a manager, you can update Dialogs, and Coaching Tips in the Production environment using theTools > Configuration option available in each process action of the case type. This feature allowsmanagers to change these options without having to wait for a rule deployment. Managers must have thesame privileges associated with the PegaCA:Manager role in order to maintain these rules.

You can give managers the ability to update other rule types in the Production environment. For example,managers can update the Goals and Deadline for a certain case type. These rules must be delegated inDesigner Studio first. For more information on rule delegation, see Delegating a rule or data type.

Application health monitoringPega Autonomic Event Services is an application that automatically monitors, retrieves, and organizes thealert data from one or more clustered systems throughout the enterprise. Pega also provides the PegaPredictive Diagnostic Cloud, which allows you to benefit from Pega Autonomic Event Services withoutinstalling it locally. Pega Predictive Diagnostic Cloud is a Software as a Service offering of Pega AutonomicEvent Services.

Implementing the following best practices in your application can help to ensure optimal response timesand overall application health:

• Segment application agent processing to a dedicated JVM (Java Virtual Machine). This configurationensures that end users do not have to share resources with background processes.

• Monitor integration response time. Over time, slow integration points can cause average handle timesto increase. When queues start to grow, it becomes very difficult to recover, which might require usageof offline services or a backup application.

Identifying and reporting issuesAs with any application, your users will encounter issues that they need to report as they begin to usethe application. When deploying your application to the production environment, complete the followingsteps:

1. Identify operational staff who will be responsible for responding to issues reported in the productionenvironment.

2. Establish procedures with those resources to triage, respond to, and escalate issues.

3. Determine procedures for delivery of changes to the production environment.


https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#designer-studio/delegating/delegating-data-types-and-rules-tsk.htm

https://pdn.pega.com/products/pega-autonomic-event-services

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#basics/v6portal/landingpages/system/pdc.htm

https://pdn.pega.com/sites/pdn.pega.com/files/help_v74/procomhelpmain.htm#basics/v6portal/landingpages/system/pdc.htm