Smart Dispute for Issuers

Transcription

1 Smart Dispute for Issuers 7.12 IMPLEMENTATION GUIDE

2 Copyright 2014 Pegasystems Inc., Cambridge, MA All rights reserved. This document describes products and services of Pegasystems Inc. It may contain trade secrets and proprietary information. The document and product are protected by copyright and distributed under licenses restricting their use, copying, distribution, or transmittal in any form without prior written authorization of Pegasystems Inc. This document is current as of the date of publication only. Changes in the document may be made from time to time at the discretion of Pegasystems. This document remains the property of Pegasystems and must be returned to it upon request. This document does not imply any commitment to offer or deliver the products or services provided. This document may include references to Pegasystems product features that have not been licensed by your company. If you have questions about whether a particular capability is included in your installation, please consult your Pegasystems service consultant. PegaRULES, Process Commander, SmartBPM and the Pegasystems logo are trademarks or registered trademarks of Pegasystems Inc. All other product names, logos and symbols may be registered trademarks of their respective owners. Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or typographical errors. This document or Help System could contain technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Pegasystems Inc. may make improvements and/or changes in the information described herein at any time. This document is the property of: Pegasystems Inc. 1 Rogers Street Cambridge, MA Phone: (617) Fax: (617) Document: Software Version: 7.12 Updated: December 2014

3 CONTENTS About This Document... i Intended Audience... i Guide Organization... i Education and Training...ii Chapter 1: Smart Dispute Overview Your Framework and PRPC Chapter 2: Extending Your Framework Structure Using DCO Tools What is DCO? Using the DCO Tools Step 1: Document Your Framework s Current Assets Step 2: Run the Application Express to Create a New Application Next Steps Step 1: Update the Built On Application Step 2: Add New Roles to the Access Group Chapter 3: What is Already Set Up System Administrator Account Ruleset Hierarchy Work Object Naming Conventions Enterprise Class Structure Layer Cake Diagram Default Work Groups, Workbaskets, and Worklists Default Portals Predefined Access Roles and Privileges Predefined Organizations, Divisions, and Units Default Service Level Rules Correspondence Templates Smart Dispute Reports Chapter 4: Understanding Smart Dispute Business Processing The Main Flow of Work in Smart Dispute Dispute Stages DisputeMainFlow Flow Diagram Qualifying the Dispute Using the TalkOff Flow Qualify Dispute Action

4 Choosing a Reason Code Using the ProcessDispute Flow ProcessDispute Flow Diagram Modifying the Provisional Credit Decision Tree Setting Up Automatic Write-Off Criteria Setting Up Write-off On Entry Evaluation Setting Up the Write-Off On Lower Threshold Setting Up Write-Off Service Levels Setting Up Write-Off Aging Thresholds Debit Transaction Dispute Processing Write-Off Criteria Process Fees with Debit Disputes ACH Commercial Disputes SEC Codes Qualify ACH Disputes ATM Processing Debit PIN: Interlink and Maestro Debit Pinless (also called Signature) Reg E Processing US Deposit Account Transaction Date Verbally Attest Set RegEPCDate and RegEFinalDate Provide Provisional Credit Reverse Provisional Credit Multi-Dispute Claim Processing Transaction Selection Qualify Fraud Other Bulk Actions Filters Accounting Correspondence Reg E at the Claim Level Claim Summary Tab Close Claim Chapter 5: Personalizing Smart Dispute Using the New Currency Control Setting up Correspondence Verification Modifying Automatic Correspondence Generation Removing the Claim Resolved Letter from the Flow Removing the Acknowledgement, Affidavit, and Follow-up Letters Modifying Conditions for Letters to Be Sent Inserting Cardholder Supporting Documentation Requests Modifying the OnUs Decision Map

5 Modifying Dispute Qualification Scripts Setting Up Duplicate Scoring Rules Using Dispute Types to Determine Work Objects Modifying Existing Processing Creating a New Association Defining and Processing New Reason Codes Defining New Reason Code Advisor Categories Defining New Bank Identification Numbers (BINs) Chapter 6: Working with Accounting Functions Setting Up Account Types Defining the Chart of Accounts Setting up Payment Types Accounting Step Rules Setting up Verification Levels Cutoff Times New Suspense Accounting Cut-off Times and the Calendar Adjusting Automatic Chargeback Understanding How Multi-currency Works Chapter 7: Smart Dispute - FSIF Integration Layer Prior to Smart Dispute 7.x Starting in Smart Dispute 7.x Smart Dispute 6.3 Application Ruleset Stack Smart Dispute 7.x Application Ruleset Stack Modified the Parent Class for Smart Dispute Classes Retrieve Customer, Account, and Transaction details from the FSIF layer Example Integration Classes in Smart Dispute Example Data Pages Used in Smart Dispute Generating Integration Classes Using the Metadata Accelerator Wizard Usage of the ExtendMapResponseData rule

6 About This Document This document describes how to configure and integrate Smart Dispute for Issuers. It is intended for those who configure or integrate the Smart Dispute software, and assumes that the software is already installed. Intended Audience Before you install, deploy, and extend your framework, it is assumed that you have attended training courses for your specific user role. Roles include: Business Managers responsible for evaluating the Framework solution and possess a general, non-technical understanding of its features and capabilities. Project Managers / Business Analysts responsible for implementing a Framework solution that can be applied to specific business requirements, and ensures compliance and continuous improvement across organizations. System Architects / Application Developers responsible for building, maintaining, modifying, and extending the Framework. System and Database Administrators responsible for the installation, security, and ongoing operational functions of the Framework such as access, tuning, and troubleshooting. Guide Organization This guide contains the following sections: Chapter 1: Smart Dispute Overview Chapter 2: Extending Your Framework Structure Using DCO Tools Chapter 3: What is Already Set Up Chapter 4: Understanding Smart Dispute Business Processing Chapter 5: Personalizing Smart Dispute Provides an overview of the framework Describes how to plan for and extend your framework structure using the PRPC Direct Capture of Objective (DCO) tools Describes the defaults and samples that are set up and ready for use Describes the Smart Dispute flows Describes some areas of Smart Dispute that you might want to modify and how to set up some functionality for your organization i

7 Chapter 6: Working with Accounting Functions Chapter 7: Smart Dispute - FSIF Integration Layer Configuring the Smart Dispute accounting functions Describes the new database integration layer. Education and Training Pega Academy's training options provide you the flexibility to learn at your own pace, in the format that works best for you and fits best into your schedule. LEARN. Learn from the experts. Pega Academy courses are designed and developed by PRPC certified experts. Each course provides design and implementation best practices covering PRPC application development as well as specialized topics. BUILD. Practice building solutions. Pega Academy courses contain exercises that take you hands-on with the product. You will implement solutions directly in the product. SUCCEED. Pega Academy courses provide you with the knowledge and hands-on experience you need to successfully design and deploy PRPC solutions. These courses also prepare you to become a Pega Certified Professional. The Pega Developer Network (PDN), is the primary technical resource area for the Process Commander developer community. The PDN contains a broad range of technical articles including troubleshooting and How-To information and a comprehensive and searchable knowledgebase to help developers speed their application development. The PDN also links directly to the customer support section of pega.com where customers can submit trouble reports and product enhancement requests. Pega Mesh is a public collaboration site, available to Pega staff, partners and customers, Pega Mesh, is the primary resource for framework specific training materials and interacting with Pega product development organization. For information on installing or working with third-party applications, such as Microsoft Visio, consult vendor documentation. ii

8 Chapter 1: Smart Dispute Overview Smart Dispute is a comprehensive rules-based solution that automates the resolution of disputes and chargebacks for credit card, debit card, Automatic Clearing House (ACH), and other consumer payment transactions. Pegasystems Business Process Management (BPM) capabilities automate straight-through processing, resolving routine dispute transactions without human intervention. Where human expertise is required, business rules ensure that your users process disputes according to your organization s policies and best practices. Smart Dispute is a packaged product designed for immediate use out of the box for reference purposes and customization. The standard Smart Dispute configuration is designed so that you can interface with other systems, personalize correspondence, set up your accounting, and define write-off levels. Smart Dispute uses Pegasystems Build for Change software, making it easy to respond quickly to association rule and internal policy changes. Finally, Smart Dispute is scalable. As your experience grows, you can extend the product to add more sophistication to your processing processing different kinds of customers or disputes differently using the patented Pegasystems rule-based architecture. The Reason Code Advisor simplifies the determination process for association reason codes. Context-based dialogs take Customer Service Representatives (CSRs) through a series of questions with each question driven by the response to the previous one. Rulebased processing analyzes the responses to determine the correct reason code and condition for a given dispute. Pegasystems Reason Code Advisor prompts the user for answers to the correct form (such as Visa Fast Track or MasterCard Expedited Dispute) for the given reason code, which reduces the dependence on specialized representatives for dispute calls. Smart Dispute is accessed through the browser, a familiar, cost-effective user interface. Any necessary software or controls are automatically downloaded when first required. Note: To adopt the new Pega 7 Responsive UI features, Smart Dispute has been tested with Internet Explorer 8 and 9, and Google Chrome, but it works best with Internet Explorer. The majority of downloaded ActiveX controls are for developers. Some ActiveX controls depend on what a user is doing, such as editing during correspondence generation. If your organization does not allow this capability, ActiveX controls are not downloaded. 1-1

9 Your Framework and PRPC Pega BPM contains a rules engine, database, processing logic, and functions providing the base on which Pegasystems Frameworks are built. Pegasystems Frameworks are layered, making use of underlying technology instead of reinventing process flows, as shown in the graphic below. Additional flows and rules are contained in the Framework layer and support application-specific functions such as contact management or customer service. The rules you modify when extending the Framework are at the top level, as they supersede the Framework defaults. Because Pegasystems Frameworks all share the same underlying technology, configuration processes, such as creating accounts and copying rules, are identical to those in PRPC. You can use the Framework rulesets as a starting point for extending the framework, making it specific to your organizational needs. 1-2

10 Chapter 2: Extending Your Framework Structure Using DCO Tools This chapter describes how to plan for and extend your framework structure using the PRPC Direct Capture of Objective (DCO) tools. Before you extend and customize the framework: Review the class structure and rules that comprise the framework. Perform a gap analysis between what is already built in the framework and what you want to implement. Create the extended structure and base rules using the Application Express. What is DCO? DCO is a suite of features that enables project team members to directly capture, organize, and manage business specifications inside PRPC and associate them with the specific parts of the application that are implementing them. Designed as an enabling technology suite, you can use DCO collaboratively and productively by project teams that include members of the business analyst, user, developer, quality assurance, and IT communities of your organization. By removing redundancies and disconnects, it helps close gaps in the development process; and fosters a Build for Change mindset that encourages reuse of application assets, automates common project activities, and generates on-demand, up to date, accurate project documents. DCO is not a methodology. It is an agile process that is adaptable to any size project and can be used with any implementation methodology. When applied consistently, DCO saves you time, effort, and budget dollars while improving and maintaining project and application quality. The end result and benefit of using DCO is a clear 360-degree view of your application through a project lifecycle. The DCO tools used to extend your framework include: Application Document Wizard supports rapid and iterative documentation of the application as development progresses using your predefined templates and content settings. Application Express lets you quickly create an application by filling out fields in a series of four screens. 2-1

11 The tool generates an initial, layered enterprise class structure and multiple rulesets, based on the input values you provide and default values entered by the system. You can use the tool to create a new organization-level class layer on which you build rules for enterprise-wide reuse. With your implementation, you can also generate a framework application and class layer, which provides a reusable foundation that can be specialized by other implementations. Using the DCO Tools This section describes how to extend your framework using the DCO tool: Document your Framework s current assets Run the Application Express to create a new application To access and use the DCO tools, log onto the framework as an administrator who is able to access Designer Studio. If you have not created a custom administrator, log in as: User: DisputeSysAdmin Password: install Step 1: Document Your Framework s Current Assets Use the Application Document Wizard to generate a Word document that lists descriptions of the assets included within the framework that can be extended. It is meant to be a business-oriented description of the processes that you can use to perform a gap analysis to determine what needs to be modified, removed, or added to meet the project scope. Because this tool documents the framework at a point in time, you can use the wizard throughout the application development process to view your progress. To document your framework s assets: 1. Select Application -> Tools -> Document. 2-2

12 2. On the Select tab, select the following options. a. In the Application section, select: Application = Smart Dispute for Issuers v07.12 for All Associations (Or SmartDispute_<AssociationName>) Template = Specification Document b. In the other sections of this tab, select the framework assets and document topics that you want to include in your output. For additional information about the options and fields on this or any other tab displayed by the Document tool, click window. to display help text in a separate 3. Click Next to move to and optionally complete the other wizard tabs. 4. Click Document Now when you are ready to generate the document. 5. Save the document. Step 2: Run the Application Express to Create a New Application Run the Application Express tool to define the class structure and rule extensions of the framework on which you want to build. 2-3

13 1. Click the Application Name displayed in the upper left hand corner of the portal and select New Application from the menu. The Create New Application screen appears. 2. Click Create New Application. 3. In the Application Overview window, enter or select the following values: Application name - Enter what is appropriate for the organization Build on Application = Smart Dispute for Issuers v07.12 for All Associations (Choose this if you are using all the associations. If you are not using all the associations, use any specific Association Applications such as SmartDispute_AMEX). Application Structure = Framework and Implementation Organization Name = Enter what is appropriate for the organization. For additional information about the options and fields on this or any other tab displayed by the Application express tool, click separate window. to display help text in a 2-4

14 4. To configure advanced settings, click the Configure advanced settings link at the bottom of the screen. 2-5

15 5. Click Save to save your changes. 6. Click Next to display the Business Objectives screen, and complete the business objectives for your application. 7. Click Next. The Case Types screen appears. By default, all the case types are selected. 2-6

16 8. Uncheck the box corresponding to each case Type that you do not need. 9. Click Next to proceed to the Data Objects screen. 10. Select all the classes to ensure that the corresponding Data classes are created at your application level. 11. Click Create to create your new application. This completes the creation of your new application. Next Steps Now that you built the base application on which to develop, you can enhance and expand the base rules and other components of the application created by the Application Express. 2-7

17 Step 1: Update the Built On Application If your new application is built on the SmartDisputeALL application rule, remove any associations and regions that are not within the scope of the target client installation. SmartDispute rulesets follow a naming convention that specifies the following: Base functionality or association-specific Where applicable for Visa, a Region can also be specified, as follows: AP: Asia Pacific Canada: Canada CEMEA: Central Europe, Middle East, Africa Europe: Europe Interlink: interbank network (primarily in US) LAC: Latin America US: United States As an example, these are possible ruleset scenarios (ignore the spaces when adding the rulesets): All Associations, All Regions Visa All Regions Visa US and Canada PegaCardSdAdvisorVisaAP:07-12 PegaCardSdAdvisorVisaAP:07-12 PegaCardSdAdvisorVisaInterlink:07-12 PegaCardSdAdvisorVisaCEMEA:07-12 PegaCardSdAdvisorVisaCEMEA:07-12 PegaCardSdAdvisorVisaCanada:07-12 PegaCardSdAdvisorVisaInterlink:07-12 PegaCardSdAdvisorVisaInterlink:07-12 PegaCardSdAdvisorVisaUS:07-12 PegaCardSdAdvisorVisaLAC:07-12 PegaCardSdAdvisorVisaLAC:07-12 PegaCardSdVisaUS:07-12 PegaCardSdAdvisorVisaEurope:07-12 PegaCardSdAdvisorVisaEurope:07-12 PegaCardSdVisaInterlink:07-12 SD Framework PegaCardSdAdvisorVisaCanada:07-12 PegaCardSdAdvisorVisaCanada:07-12 PegaCardSdVisaCanada:07-12 PegaCardSdAdvisorVisaUS:07-12 PegaCardSdAdvisorVisaUS:07-12 PegaCardSdVisa:07-12 PegaCardSdVisaAP:07-12 PegaCardSdVisaAP:07-12 PegaCardSdAdvisorVisa:07-12 PegaCardSdVisaUS:07-12 PegaCardSdVisaUS:07-12 PegaCardSdConfig:07-12 PegaCardSdVisaCEMEA:07-12 PegaCardSdVisaCEMEA:07-12 PegaCardSdAdvisor:07-12 PegaCardSdVisaInterlink:07-12 PegaCardSdVisaInterlink:07-12 PegaCardSdIssuer:07-12 PegaCardSdVisaLAC:07-12 PegaCardSdVisaLAC:

18 All Associations, All Regions Visa All Regions Visa US and Canada PegaCardSdVisaEurope:07-12 PegaCardSdVisaCanada:07-12 PegaCardSdVisa:07-12 PegaCardSdAdvisorVisa:07-12 PegaCardSdMasterCard:07-12 PegaCardSdAdvisorMasterCard:07-12 PegaCardSdAMEX:07-12 PegaCardSdVisaEurope:07-12 PegaCardSdVisaCanada:07-12 PegaCardSdVisa:07-12 PegaCardSdAdvisorVisa:07-12 PegaCardSdConfig:07-12 PegaCardSdAdvisor:07-12 PegaCardSdIssuer:07-12 PegaCardSdAdvisorAMEX:07-12 PegaCardSdConfig:07-12 PegaCardSdAdvisor:07-12 PegaCardSdIssuer:07-12 Step 2: Add New Roles to the Access Group Once you build the new application, add the following roles to the new access group. Failure to do this results in transaction errors in the dispute process. 2-9

19 2-10

20 Chapter 3: What is Already Set Up This chapter describes defaults and samples that are set up and ready for use. It is expected that you use these as a basis for extending the Smart Dispute Solution Framework. The topics include: System Administrator Account Ruleset Hierarchy Data Classes Data Tables Work Object Naming Conventions Default Work Groups and Workbaskets Default Operators and Access Groups Default Portals Predefined Access Roles and Privileges Predefined Organizations, Divisions, and Units Default Service Level Rules Correspondence Templates Smart Dispute Reports Reporting Gadgets Sample Database Model System Administrator Account The Smart Dispute for Issuer Framework uses the following Operator ID as the default system administrator account: Operator ID: DisputeSysAdmin Password: install This Operator ID gives you access to the developer portal and all rules and files. Note: Operator IDs are not case-sensitive, but passwords are case-sensitive. 3-1

21 Ruleset Hierarchy Rulesets are arranged hierarchically, with general rules at the bottom and specific rules at the top. The four rulesets at the bottom are standard in all applications and control the underlying PRPC operations, while the rules at the top control application functions. The ruleset order is critical to rule resolution. To find the appropriate rule, PRPC begins with the top ruleset in this list, and if the rule is not found, it moves to the next ruleset. In this manner, custom, site-specific rules have precedence over application-specific rules. The following shows the ruleset hierarchy with all the PegaCARD Smart Dispute Solution Framework layers. 3-2

22 You must configure your rulesets at the top of the stack. The PRPC rulesets are located below this stack. 3-3

23 Work Object Naming Conventions When your application initiates a work object, a predefined model populates key property values, such as urgency, that directly affect the work object s relative priority and placement in operator worklists. As work objects progress towards resolution, core property values, such as priority and status, are continually updated to reflect the current stage of processing. The prefixes currently defined are: C- for claim work objects D- for dispute work objects Enterprise Class Structure Layer Cake Diagram The following is a sample enterprise class structure for Smart Dispute Framework. Sample Enterprise Class Structure Extending Smart Disputes Division Reuse layer Implementation Layer Cramework Layer Corp-App-Disputes Dispute Int- Work- Dispute Enterprise Reuse layer Corp- FW- Data- Int- Corp-Div- Data- Int- Data- Int- Work- Corp-FW-DisputesFW- Data- 3-4

24 Default Work Groups, Workbaskets, and Worklists The following lists the default work groups, workbaskets, and worklists found in the PegaCARD Smart Dispute Work Groups Disputes Merchant Workbasket Arbitration Duplicates Representment AssociationSLA Exceptions RetrievalRequest ChargeBackPending Fraud SDAging CheckInCandidates GoodFaith SDCutOff International SdOperations Compliance OnUs SDVerification CustomerClaim PendingDocument SDWriteOff PendingResearch Visa DisputeReviewRequired Disputes PendingResponse QualifyCustClaimWB Smart Dispute ships with the operators and access groups listed in the following table. All passwords are set to install by default. Operator DisputeSysAdmin Access Group DisputeSysAdminUserALL DisputesManager DisputesManager DisputesManager DisputesOperator DisputesOperator DisputesOperator DisputesOperator DisputesOperator DisputesOperator DisputesOperator DisputesOperator 3-5

25 Default Portals Developer Portal The Developer portal is used by developers and business architects to access the Designer Studio for creating and updating rules. This portal is available to all operators who have the DisputeSysAdminUserALL access group configured. Sample operator user ID andpassword for this access group is Disputesysadmin and install. CaseUser7 Portal The CaseUser7 portal is used by Dispute Operators for creating disputes. This portal is available to all operators who have the DisputesOperator access group configured. Sample operator user ID and password for this access group is and install. 3-6

26 CaseManager7 Portal The CaseManager7 portal is used by managers to create work and supervise the created work. The charts configured on the home screen provide an overview of the application. Additional reports can be accessed through the Reports link available on the home screen. This portal is available to all operators who have the DisputesManager access group configured. Sample operator user ID and password for this access group is and install. 3-7

27 Predefined Access Roles and Privileges Your framework includes a set of predefined access roles and privileges. Privileges Dispute Entry Fraud Manager Dispute Processing Clerical Supervisor SysAdmin Adjustment X X X ClosePayable X X X X X CloseReceivable X X X X X CutoffCancel X X X CutoffForce X X X CutoffRelease X X X Dispute1 X X X X X X Dispute2 X X X X X Dispute3 X X X DupSearch X X X X X X X ForceWriteOff X X X GetNewWorkFromConf X X X X X X X InitiateCollection X X X X X OpenPayable X X X X X X X OpenReceivable X X X X X X X RescheduleWriteOff X X X RespondCollection X X X X X Transfer X X X X X X X TransferWorkBasket X X X X X X X VerifyLevel1 X VerifyLevel2 X VerifyLevel3 X WriteOffAdjustment X X X WriteOffAged X X X WriteOffPayable X X X WriteOffReceivable X X X 3-8

28 Predefined Organizations, Divisions, and Units Smart Dispute comes with the following predefined organization, division, and units. Organization: Pega.com Division: Units: Administration Installation Default Service Level Rules The default service levels assign an initial urgency value for a dispute and add to it at goal time and deadline time. Value-based urgency is calculated in the Rule-Declare-Expression rule. By default, it adds additional points for amounts less than $100.00, less than $500.00, and anything over $ This rule controls the urgency value for every work object type. If the default values are acceptable for your organization, you can use them; otherwise, you can change them. To change the time-based urgency points, enter new values in the Initial, Goal, Deadline, and Late fields of the Service Level rule form (as described in the previous topic). The following table lists the default Service Level Rules that come with Smart Dispute, along with the default goals and deadlines. Name Goal Deadline ActionFulfillment 30 days 44 days ActionMediationRuling 2 days 2 days ActionMediationRuling 3 days 7 days ActionMediationRulingNF 8 days 10 days ActionNonFulfillment 1 day 2 days AnswerQuestions 5 days 10 days AppAddContact 1 day 1 day ArbCBInitiation 30 days 45 days Arbitration 1 day 1 day ArbitrationWB 25 days 30 days ArbitrationWBIntl 30 days 45 days AssignForAgedWriteOff 180 days 210 days AssociationSLA - - ChargebackReversalAssign 1 day 1 day CheckForResponse30 1 day 2 days CompleteInvestigation - - Compliance 1 day 1 day ComplianceWB 30 days 30 days 3-9

29 Name Goal Deadline ComplianceWBInt 75 days 90 days ConfirmReversePCFromClaim - - DecisionInboundArbitration 20 days 30 days DisputeMainFlow 30 days 60 days DisputeMainFlowOld 30 days 60 days EscalateCompleteInvestigation - - FinAgedWriteOff 90 days 90.0 days FinStepCutoff 5 hours 10 hours FinWriteOffAfter30 30 days 30 days FinWriteOffAfter60 60 days 60.0 days FinWriteOffAfter90 90 days 90.0 days GoodFaithOutbound 30 days 30 days GoodFaithWB 25 days 30 days GoodFaithWBOutbound 25 days 30 days HasDuplicates 1 day 1 day InboundArbitration 25 days 30 days InboundCompliance 20 days 30 days InboundPreArbitration 20 days 30 days InitiatePreArbitration 1 day 1 day InvokeInsertDisputeDetails 3 minutes 5 minutes Mediation7 1 day 1 day NonFulfillmentAssignment 1 day 3 days Operator 1 day 1 day PayableWriteOffSLA 150 days 180 days PendChargeback - - PendForFullfillment 30 days 31 days PendingCardholderResponse 2 minutes 5 minutes PendingFeeCollection 10 days 12 days PendingFundsDisbursement 10 days 12 days PreArbitration 30 days - PreArbitration 1.0 days 5 seconds PreArbitrationOutbound 30 days 30 days PreArbitrationWB 25 days 30 days PreComplianceOutbound 30 days 30 days PreComplianceWB 25 days 30 days PreComplianceWBOutbound 25 days 30 days ProcessChargeback 1 day 2 days ProcessDispute 5 days 10 days 3-10

30 Name Goal Deadline ProcessDuplicateRequests 1 day 1 day ProcessFinalCredit - - ProcessOnUsDisputes 2 days 5 days ProcessSecondChargeback 45 days 60 days ProcessSecondChargeback 45 days 60 days QualifyDispute 1 day 2 days QuestionToContinueDispute 1 minute 2 minutes QuestionToContinueTalkOff 1 minute 2 minutes ReceivableWriteOffSLA 150 days 180 days RegZCredit 59 days 60 days RegZCredit 1 day 2 days Representment 5 seconds 5 seconds RepresentmentAssignment 30 days 45 days RepresentmentDocAssignment 21 days 22 days ResolveChargeback 30 days 31 days ReverseProvisionalCredit - 1 minute ReverseProvisionalCreditFromClaim - - SendEditAcknowledgeLetter 1 day 2 days SendEditCardHolderLetter 1 day 2 days SendEditCoverLetter 1 day 2 days SendEditGoodfaithLetter 1 day 2 days SendEditMCCoverLetter 1 day 2 days SendEditPreArbitrationLetter 1 day 2 days SendEditPreCompliance 1 day 2 days SendEditVisaCoverLetter 1 day 2 days Standard 30 days 60 days TalkOffProcess 1 minute 2 minutes Untimely 1 day 2 days WaitForDocument 10 days 20 days WaitForDocument 8 days 10 days WaitForNACHA - - WaitForRegEFinal WaitForRegEFinal WaitForRegEPCDate - - WaitForSignedAffidavit 8 days 10 days WaitToCloseCover - 1 day WriteOffAfter minutes 5 minutes 3-11

31 Note: SLAs with empty goals and deadlines are created for easier extensibility. Smart Dispute also provides an Association service level rule that monitors the dispute according to the association requirements and takes steps to override the dispute servicelevel rule if the association timeframes are threatened. This allows you the flexibility to establish service level rules that meet your business needs and at the same time ensure that association timeframes are not missed if the business service level is not met. The Association service-level processing follows the steps below using specified goal and deadline days. Assume the Association service level goal and deadline are set as follows: Goal: Association deadline is 32 calendar days Deadline: Association deadline is 2 additional calendar days When or if the Association goal date is reached, Smart Dispute updates the dispute goal and deadline dates as follows: Dispute Goal Date: Set to the Association service-level goal date Dispute Deadline Date: Set to the Association service-level deadline date When or if the Association deadline date is reached, Smart Dispute: Routes the Association service level assignment to the Exceptions workbasket Includes the following instruction on the assignment: Warning: Association Deadline May Be Missed You can assign different urgency values based on the originator of the work object. You can add more urgency points based on the dollar value of the work object. The user interface lists work objects with higher urgency totals at the top of the worklists and workbaskets. Correspondence Templates Smart Dispute provides the ability to generate correspondence for the claim. At the claim level, sample templates are available to generate correspondence for: Acknowledgements Affidavits Reminders Resolution details In addition, workflow processes can generate correspondence for individual disputes. The following workflows use templates to generate the following correspondence: Write-off Cardholder liable 3-12

32 Chargeback Outbound good faith Outbound pre-compliance Outbound pre-arbitration Arbitration inbound and outbound Compliance inbound and outbound In addition to these automatically generated correspondence types, users with the appropriate privileges can generate correspondence at any point. The following table lists the Smart Dispute templates that are part of the framework. PRPC also comes with a standard set of correspondence templates for Work- (not shown). Class Name Stream Name Corr Type PegaCard-Sd-Claim CustomerLiableCorrTemplate PegaCard-Sd-Claim PegaCard-Sd-Claim PegaCard-Sd-Claim PegaCard-Sd-Claim PegaCard-Sd-Claim PegaCard-Sd-Claim PegaCard-Sd-Claim- PegaCard-Sd-Claim- PegaCard-Sd-Claim- PegaCard-Sd-Claim- PegaCard-Sd-Claim- PegaCard-Sd-Claim- PegaCard-Sd-Debit PegaCard-Sd-Debit PegaCard-Sd-Debit PegaCard-Sd-Debit PegaCard-Sd-Debit ProvisionalCreditCorrNotification ConfirmReversePCCorrFromClaim CloseClaimCorrespondenceTemplate FraudAffidavitCorrespondence ProvisionalCreditFinalNotice NotifyReverseProvisionalCredit ResearchingClaim ResolvedClaim Header Footer CardHolderAffidavitClaim AcknowledgeClaim ReverseProvisionalCreditNotification FinalCreditWithFee ProvisionalCreditNotification PCFinal PCWithFeeFinal 3-13

33 Class Name Stream Name Corr Type PegaCard-Sd-Debit ReverseProvisionalCreditAndFeeNotification PegaCard-Sd-Debit PegaCard-Sd-Debit PegaCard-Sd-Debit PegaCard-Sd-Debit PegaCard-Sd-Debit PegaCard-Sd-Debit PegaCard-Sd-Debit PegaCard-Sd-Debit PegaCard-Sd-Debit-ACH PegaCard-Sd-Debit-ACH PegaCard-Sd-Debit-ACH PegaCard-Sd-Debit-ACH PegaCard-Sd-Dispute PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- ReminderToReturnWSUD EscalateToSupervisor RequestPOA NoticeToReversePC FinalCredit SorryLetter ProvisionalCreditWithFeeNotification ReminderToReturnDocument ProvisionalCreditWithFeeNotification CreditNoticeFeesOnly ProvisionalCreditNotification SorryLetter Footer VisaHeader CardHolderLiable ResolvedCardholderFavor AcknowledgeSample CardHolderAffidavit Footer GeneralCoverLetter GeneralHeader GoodFaithLetter Header PreArbitration PreComplianceLetter AcknowledgeLetter

34 Class Name Stream Name Corr Type PegaCard-Sd-Dispute- AcknowledgeSample PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- CardHolderLetter CHLetter62_3 ClosedNoReply Footer FullfillmentLetter Header Reminder RequestForInformation RequestToContactMerchant ResolvedCardholderFavour VisaCoverLetter CardHolderLiable EBDBillingDiscrepancies EBDCanceledServicesReturnedMerchandise EBDDefectiveNotAsDescribed EBDNonReceiptOfMerchandise EBDNotElsewhereClassified EBDResolutionProcessForm EBDServicesNotRendered EXPBillingForm GoodFaithLetter Header IssuerCertificationTemplate MCCoverLetter MCHeader PaymentByOtherMeans 3-15

35 Class Name Stream Name Corr Type PegaCard-Sd-Dispute-MC- PreArbitration PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-MC- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- RegulationsRulesViolation RegulationsRulesViolationPreCom RequestToContactMerchant ResolvedCardholderFavor SummaryOfArbitrationDocumentation MEBNoShowDisputeForm AddendumDispute POICrncyConversionDisputeEBF EXPBillingFormFor4831 InstallmentBillingDispute ResolvedCardholderFavor TransactionInformation AdditionalInformation CardholderInformation Exhibit2E2 Exhibit2E_1 Exhibit2E_2 Exhibit2E_3 Exhibit2E_4 Exhibit2E_5 Exhibit2E_6 Header IssuerCertificationTemplate IssuerCertificationTemplt MemberContactInformation MemberInformation 3-16

36 Class Name Stream Name Corr Type PegaCard-Sd-Dispute-Visa-International- RequestForInformation PegaCard-Sd-Dispute-Visa-International- PegaCard-Sd-Dispute-Visa-International- Canada- VisaHeader Exhibit2E_2 Using and Modifying Correspondence The Create Correspondence processing option uses the pre-configured correspondence templates. Copy the appropriate rules to the production work class and modify them as necessary. Some correspondence rules are called top-level rules (indicated on the Prompts tab of the rule form). Master templates are based on a top-level correspondence rule and can include other rules or references to other rules. The correspondence type whether , mail, phone, or fax is defined in the top-level correspondence rule when it is created. The rules define various correspondence segments such as the header, footer, and body. Each segment (or stream) provides a piece of the HTML code needed to generate a complete piece of correspondence. The advantage of defining Correspondence fragments as separate rules is that they can be re-used in many correspondence templates. Because the correspondence is HTML-based, it provides the opportunity to create a professional look and feel to letters, s, and faxes that are sent to customers and banks. s are generated through capabilities built into PRPC. The routing, printing, and faxing of correspondence are handled by an interface to the PegaDISTRIBUTION MANAGER. However, it is not necessary to have PegaDISTRIBUTION MANAGER installed when updating and testing changes to the templates. Correspondence is generated, attached to the claim or dispute, and can be reviewed online in its printed form. It does not print until the interface is active. Tip: To copy and customize the templates in your ruleset, maintain the same Correspondence Rule name to avoid unnecessary updates to workflow elements that call specific templates. Add templates only when no alternative is available. Smart Dispute Reports Smart Dispute comes with a set of reports that you can use as-is or modify as needed for your business. 3-17

37 This section contains the full list of available reports, organized in the categories listed below. Accounting Reports Report Name Outstanding Suspense Outstanding Suspense Age Outstanding Suspense Amount Range Resolution of Suspense Graph Chargebacks Report Name Chargebacks by Reason code Chargebacks by Reason code Graph Regulation E Reports Report Name Open Cases by Reg E Final Date Open by Reg E Final Date Next 7 Days Open by Reg E Final Date Next 30 Days Open Cases by Reg E PC Date Open by Reg E PC Date Next 7 Days Open by Reg E PC Date Next 30 Days Reg E Audit Report, Open Items Reg E Audit Report, Resolved Items Graph Representments Report Name Representments by Reason Code Graph Write-Offs Report Name Write Offs By Visa Region Report Write Offs By Reason Code Write Offs By Reason Code Write Offs By Visa Region Graph 3-18

38 Chapter 4: Understanding Smart Dispute Business Processing Processing in Smart Dispute is controlled by flows. These flows determine which screens you see and which processing occurs in the background. Smart Dispute contains many flows, which interact with each other. Smart Dispute processing begins with the DisputeMainFlow. This flow calls multiple additional flows, depending on the exact details of the dispute that you enter. This chapter describes three flows: DisputeMainFlow TalkOff ProcessDispute The Main Flow of Work in Smart Dispute DisputeMainFlow is the backbone of Smart Dispute processing for credit card and debit dispute processing. It starts when you enter a dispute and calls multiple additional flows, depending on the details of the dispute that you enter. When you access an account and select a specific transaction to dispute, Smart Dispute searches to see if this dispute already exists, or if there are any other pending disputes that might be associated with the current dispute. Smart Dispute analyzes the details of the transactions and displays a list of disputes that might be duplicates of, or related to, the current dispute. If there are multiple potential duplicate disputes, Smart Dispute ranks them according to which other disputes most closely match the current dispute. This step is part of the DuplicateSearch Invoke Flow shape shown in the DisputeMainFlow Flow Diagram section. Smart Dispute then checks if a credit has been issued to the account since the transaction date of the disputed amount. This step is part of the CreditSearch Invoke Flow shape shown in the n the DisputeMainFlow Flow Diagram section. The next step in the flow depends on the Dispute Stage, as determined by the value of the DisputeStage property. The Dispute Stage shows the position of the dispute within Smart Dispute s processing. The Dispute Stage changes as Smart Dispute processes the dispute. Dispute Stages In the extreme scenario where a Dispute continues throughout the entire adjudication process, the following Dispute Stages occurs. 4-1

39 Smart Dispute checks if the Dispute Stage is Representment, PreArbitration, Compliance, or Good Faith. This step is part of the first fork in the DisputeMainFlow Flow Diagrams ection. The following table lists the flows and their function, based on the Dispute Stage. Dispute Stage Name of Flow What the Flow Does Representment Representment Creates an assignment to be worked for a Representment that has been received. Also creates an accounting suspense entry. PreArbitration PreArbitrationInbound Creates an assignment to record a response to a prearbitration request, produces correspondence, updates the dispute status, does accounting, and so on, depending on the details of the dispute. Compliance PreComplianceInbound Creates an assignment to record a response to a precompliance request, produces correspondence, updates the dispute status, does accounting, and so on, depending on the details of the dispute. Good Faith GoodFaithInbound Creates an assignment to record a response received from an acquirer, indicates whether the acquirer granted or declined the request, and determines how any remaining balance is to be treated. If the Dispute Stage is other than one of the values listed in the preceding table, then Smart Dispute continues to the OnUsProcessing flow. This flow lets you process disputes differently if your bank is both the issuer and the acquirer for the transaction. This step is part of the OnUsProcessing Invoke Flow shape shown in the DisputeMainFlow Flow Diagram section. If your organization processes On-Us and non-on-us disputes the same, you can remove the On-Us Flow from the Dispute Main Flow. The Representment, PreArbitrationInbound, PreComplianceInbound, GoodFaithInbound, and OnUsProcessing flows handle disputes that do not have chargeback rights. Disputes that may have chargeback rights continue to the TalkOff flow. This flow lets you enter the initial information about the call and determine whether you should continue with the dispute. This step is part of the TalkOff Invoke Flow shape shown in the DisputeMainFlow Flow Diagram 4-2

40 section. For step-by-step information about the TalkOff flow, see Qualifying the Dispute using the TalkOff Flow section. Smart Dispute calls the SmallDollarWriteOff flow. This flow evaluates the details of the transaction to determine if it should be written off. This step is part of the SmallDollarWriteOff Invoke Flow shape shown in the DisputeMainFlow Flow Diagram section. There is a separate write-off decision table for debit transactions, called IsWriteOff. See Debit Transaction Dispute Processing. After the SmallDollarWriteOff flow, Smart Dispute continues to the RegulationZCredit flow. This flow is used only if the communication from the cardholder satisfies the requirements of the United States Fair Credit Billing Act (FCBA). If the FCBA applies, this flow manages the timeframes to ensure that all the steps of the dispute process that have time limits specified by the FCBA, or by Regulation Z, are completed within those time limits. This step is part of the RegulationZCredit Invoke Flow shape shown in the DisputeMainFlow Flow Diagram section. For debit transactions, Smart Dispute determines if the transaction or dispute is subject to Reg E (Regulation E is a US consumer rights law which covers electronic transactions posted to customers deposit accounts) and if so, by which dates certain processing steps need to be completed. See the Debit transaction Dispute Processing section. Next, the ProvisionalCreditEvaluate utility automatically evaluates the details of the dispute and the customer account. It determines if the circumstances of the current dispute fall within the established guidelines to grant a provisional credit immediately. If so, it sets the value of the ProvisionalCredit property to Y, and calls the SuspenseOpen flow. This flow handles the accounting for a provisional credit to the cardholders account. This step is part of the SuspenseOpen Invoke Flow shape shown in the DisputeMainFlow Flow Diagram section. After the SuspenseOpen flow, Smart Dispute continues to the ProcessDispute flow. Smart Dispute also calls this flow if the transaction is a credit, or if the cardholder has not been granted a provisional credit. The ProcessDispute flow helps you choose a reason code for the dispute and manages timeframes to ensure that the dispute processing happens within established time guidelines. This step is part of the ProcessDispute Invoke Flow shape shown in the DisputeMainFlow Flow Diagram section. For step-by-step information about the ProcessDispute flow, see the Choosing a Reason Code using the ProcessDispute Flow section. DisputeMainFlow also includes other utilities and tickets that manage internal details for the Smart Dispute program. DisputeMainFlow Flow Diagram The DisputeMainFlow diagram shows the backbone of Smart Dispute processing for credit card disputes. 4-3

41 Qualifying the Dispute Using the TalkOff Flow The TalkOff flow determines which actions you can take and which screens you see during the initial entry of a dispute. The flow assists you in determining if the dispute can be resolved or processed further. The possible actions are: Qualify Dispute Action Resolve Dispute with Merchant Action 4-4

42 Ask Cardholder to Contact Merchant Action Enter Dispute Details Action These actions are described in the following sections. Depending on the details of the dispute and the information that you provide, the TalkOff flow might also call other flows. See the TalkOff Flow section. Qualify Dispute Action If the cardholder initiated the dispute, Smart Dispute may recommend that you qualify the dispute. This step presents you with a set of questions and decisions that classifies the dispute and helps determine whether the dispute can be resolved, marked as fraudulent, or processed further. This process enables the system to accept only disputes that have been properly qualified according to business best practices, thereby reducing false claims and error rates. This step is part of the QualifyDispute Assignment shape shown in the TalkOff Flow Diagram section. Note: To assist in qualifying the dispute, you can view additional information about the transaction and merchant under the Work Information section of the screen. Smart Dispute uses the answers that you provide to these questions to determine the next steps in processing the dispute. For example, Smart Dispute may suggest using the Resolve Dispute with Merchant talk-off script if the: Cardholder initiated the dispute Dispute is regarding goods and services Cardholder has not attempted to resolve the issue with the merchant If the cardholder has already attempted to resolve the issue with the merchant, Smart Dispute does not suggest the Resolve Dispute with Merchant talk-off script. If the cardholder does not recognize the transaction, Smart Dispute may suggest using the Assist Cardholder in Identifying Transaction talk-off script. This script includes questions that help the cardholder to identify the transaction. It is part of the IdentifyTransaction flow. If appropriate, the IdentifyTransaction flow calls other flows that process fraudulent activity or a lost or stolen card. This step is part of the IdentifyTransaction Invoke Flow shape shown in the TalkOff Flow Diagram section. Smart Dispute continues processing the dispute, based on the answers that you provide to these questions. These are two examples; however, you can customize the questions that Smart Dispute presents, as well as the processing that occurs in the background. You can easily modify the flows and logic that drive them to fit the specific needs of your organization. 4-5

43 The answers that you provide are also retained by the system for future use in case processing, including reason code determination in the Reason Code Advisor, and identifying fraudulent activity. Resolve Dispute with Merchant Action If the cardholder has a goods or services dispute and the dispute has not been qualified, Smart Dispute may display the Resolve Dispute with Merchant talk-off script. This script encourages the cardholder to contact the merchant and resolve the dispute directly. This step is part of the QuestionToContinueDispute Assignment shape shown in the TalkOff Flow Diagram section. Smart Dispute resolves the dispute, or continues processing, based on your answers to the questions. Ask Cardholder to Contact Merchant Action If you specify sending a letter to the cardholder, Smart Dispute recommends the Ask Cardholder to Contact Merchant action. This step is part of the SendEditCorr Assignment shape shown in the TalkOff Flow Diagram section. Smart Dispute creates the letter to the cardholder, so that it is available to be sent. The letter recommends that the cardholder contact the merchant to resolve the dispute directly. Enter Dispute Details Action Smart Dispute may recommend the Enter dispute details action. This step is part of the InvokeInsertDisputeDetails Assignment shape shown in the TalkOff Flow Diagram section. Smart Dispute continues processing the dispute. Smart Dispute uses the FCBA check box to determine qualifications for the special processing required by Federal Reserve Regulation Z. TalkOff Flow Diagram The TalkOff Flow diagram shows the call flow while you enter the initial information about the call and determine if you should continue with the dispute. 4-6

44 Choosing a Reason Code Using the ProcessDispute Flow The ProcessDispute flow helps you choose a reason code for the dispute. The actions that it might display are: Initiate Reason Code Advisor Action Answer Ancillary Questions Action 4-7

45 These actions are described in the following sections. Depending on the details of the dispute, and the information that you provide, the ProcessDispute flow might also call other flows. See the ProcessDispute Flow Diagram section. Initiate Reason Code Advisor Action After the dispute has been qualified, Smart Dispute can assist in determining the reason code with the Reason Code Advisor. Smart Dispute uses the information that you provide to determine the reason code or the next steps in processing. Answer Ancillary Questions Action If Smart Dispute needs to collect additional information, it recommends the Answer Ancillary Questions action. Smart Dispute uses the information that you provide to determine the reason code or the next steps in processing. Reason Code the Smart Dispute Building Block The Reason Code is the basis for how a dispute will be processed. Each reason code can be further specified using a Condition Code where needed. For example, there can be more than one way to handle a Not as Described dispute. If this is the case, then a Condition Code for each specific scenario is used. Each Reason Code is comprised of the following entities and properties: Time Frames: Primary and Secondary Timeframes apply to specific properties based upon conditions. Documents: Inbound and Outbound documentation. Details: the Ancillary Questions and Message Text, as well as a Fraud indicator. Next: used to control the flow processing. A Ticket Retrieval can be set at mandatory, along with a Retrieval Flow. The Chargeback Flow is specified. There is a flag for First or Second Chargeback and the ability to limit the dollar amount for the dispute. Limits: Textual notes for the Customer Service agent, Limits are designed as guidelines, rather than validated restrictions. Representment Time Frames: specific time frames for the Representment stage. 4-8

46 ProcessDispute Flow Diagram The ProcessDispute flow helps you choose a reason code for the dispute. It calls other flows that manage timeframes to ensure that the dispute processing happens within established time guidelines, and to do the accounting for the chargeback. 4-9

47 Modifying the Provisional Credit Decision Tree The 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. Smart Dispute comes with a provisional credit decision tree that you can use or modify if your business rules change. To modify the provisional credit decision tree: 1. Click the Records Explorer tab. 2. Select Decision > DecisionTree to display a list of rules. 3. Click IsProvisionalCredit to display a Decision Tree form, shown below. 4-10

48 4-11

49 4. Click Save As. 5. In the Save As form, select ClassName-Sd-Dispute- from the Class Name list (where ClassName is your top-level class name), select your ruleset from the selection box, and then 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 don t 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 result count. 7. Click Save. Setting Up Automatic Write-Off Criteria Your organization may have a policy that unresolved suspense entries are written off if the amount involved is below a certain threshold. There are four types of write-off rules that you can adapt for your use: Write-Off on Entry Write-Off on Lower Write-Off Service Level Write-Off Aging Threshold Setting Up Write-off On Entry Evaluation Smart Dispute 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 on criteria such as account details, amount, and dispute history. The write-off workflow uses the write-off decision tree to capture best practice business logic and uses it to make automated decisions To modify the write-off decision tree: 1. Click the Records Explorer tab. 4-12

50 2. Select Decision > DecisionTree to display a list of rules. 3. Click IsWriteOff to display the Decision Tree form, shown below. 4-13

51 4. Click Save As. 5. In the Save As form, select ClassName-Sd-Dispute- from the Class Name list (where ClassName is your top-level class name), select your ruleset from the selection box, and then click Save As. 6. Edit the If statements as necessary. Enter a comparison starting with one of the comparison operators <, >, <>, =, == (Java identity), >= or <=. If you don t 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 result count. 7. Click Save. Setting Up the Write-Off On Lower Threshold A map value threshold is used whenever a suspense entry type of Lower is created on a dispute. The default value is $0.00. For example, after a partial chargeback the value defined in the WriteOffOnLower threshold determines if the remainder should be automatically written off. To change a threshold: 1. Click the Records Explorer tab. 2. Select Decision > MapValue to display a list of rules. 3. Click WriteOffOnLower to display a Decision Tree form, as shown below. 4-14

52 4. Click Save As. The Save As form appears. 5. In the Save As form, select ClassName-Sd-Dispute- from the Class Name list (where ClassName is your top-level class name), select your ruleset from the selection box, and then 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 Write-Off Service Levels Smart Dispute lets you set an SLA on open suspense items. Smart Dispute 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 reached. The default write-off period is 180 days, at which time Smart Dispute suggests that an open suspense item should be written off which closes items when the likelihood of recovering funds is low. To change your write-off service level rule: 1. Click the Records Explorer tab. 4-15

53 2. Select Process > ServiceLevel to display a list of rules. 3. Click ReceivableWriteOffSLA to display the Service Level form, shown below. 4. Click Save As. 5. Select ClassName-Sd-Dispute- from the Class Name list (where ClassName is your top-level class name), select your ruleset from the selection box, and then click Save As. 6. Update the Goal and Deadline values as necessary. 7. Click Save. Setting Up Write-Off Aging Thresholds The length of time an open suspense accounting item must wait, or age, before being written off is determined by two MapValue rules, ReceivableWriteOffSLA (for receivable accounting) and PayableWriteOffSLA (for payable accounting). To change the aging thresholds: 1. Click the Records Explorer tab. 2. Select Process > Service Level to display a list of rules. 3. Click PayableWriteOffSLA or ReceivableWriteOffSLA. 4. Click Save As. 4-16

54 5. Select ClassName-Sd-Dispute from the Class Name list (where ClassName is your top-level class name), select your ruleset from the selection box, and then click Save As. You can specify an age threshold or you can set the age threshold based on the outstanding balance. 6. Click Save. Debit Transaction Dispute Processing Processing flow for debit processing (ACH, ATM, and debit Pin and Pinless transactions) begins with the DisputeMainFlow as well, but branches off depending on the transaction. Write-Off Criteria You can set distinct write-off criteria for debit or deposit account disputes in the IsWriteOff decision table, shown below. Process Fees with Debit Disputes Reg E requires the return of fees and interest if they were caused by a disputed transaction. Prior to granting Provisional Credit for debit transactions, SD simulates integration to the bank s deposit account system to return any fees posted to the account since the transaction date, so the user can decide if any or all of these various fees need to be credited back to the customer. Use the SelectChargeFees flow as an integration point to present the appropriate fees to the user. 4-17

55 ACH Commercial Disputes SEC Codes Commercial SEC codes in ACH transactions are typically handled with a different SLA and by a different set of operators. A When condition evaluates the SEC code to determine if the transaction should be processed as a commercial dispute. If the SEC code is CCD, the ACH return reason R05 is set; SEC code of CTX sets R31 return reason. For either of these SEC codes, the customer is given immediate credit and the dispute status is Resolved- WrittenOff. 4-18

56 The CommercialDisputeFlow flow can be updated for further extension and reusability. 4-19

57 Qualify ACH Disputes The 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. ATM Processing Sample reason code rules for Pulse and On Us ATM transactions are configured. ATM reason codes include Wrong Amount, Duplicate Transaction, and Do Not Recognize. You can extend these rules for other error descriptions, as well as for other ATM networks in which the bank participates. Debit PIN: Interlink and Maestro Smart Dispute includes reason code rules for Visa s debit card network Interlink, and Master Card s debit network Maestro. Debit Pinless (also called Signature) Smart Dispute includes reason code rules for Visa and Master Card, along with Reason Code Advisor to help Dispute operators correctly select the appropriate reason code. 4-20

58 Reg E Processing Smart Dispute has incorporated decision rules to ensure compliance with the US consumer regulation called Regulation E, or Reg E. The processing includes setting deadlines for Provisional Credit and investigation completion, as well as structured customer notification specified by the regulation. US Deposit Account The IsUSDepAccount When rule checks that the account holder s primary address has a country code of US, and that the account type is checking or savings. Transaction Date The Datatransform rule SetNoRegECredit date sets the date before which a transaction is not subject to Reg E by reading the account s statement cycle date, and calculating the first date of the second to the last statement. The IsRegECreditRequired When rule compares the SetNoRegECredit date to the transaction date to determine if the dispute is subject to Reg E. 4-21

59 Verbally Attest The VerballyAttest flow action allows you to indicate whether the customer has verbally confirmed the validity of their dispute and is therefore not required to sign a document with that confirmation. Set RegEPCDate and RegEFinalDate The EvaluateRegEDates activity sets the dates for giving Provisional Credit (RegEPCDate) and for completing the investigation (RegEFinalDate). The activity sets the RegEPC date to +10 business days from Case Creation date, and sets the RegEFinal date to +45 calendar days from Case Creation date if all of these statements are true: Account holder's address is in the US Transaction was on the customer's last 2 statements CHIdMethod is not 2 (a 2 in this field means customer entered a Pin at the point-ofsale) Transaction Currency is the same as Posting currency Sets the RegEPC date to +20 business days if: The Account Open date is less than 30 days ago Sets the RegEFinal date to +90 calendar days from Case Creation date if these two statements are true: Account holder's address is in the US Transaction was on the customer's last 2 statements And either of the two statements is true: CHIdMethod is 2 or Transaction Currency is not the same as Posting currency 4-22

60 Provide Provisional Credit The IsEligibleForREGEPC When rule determines if the customer is eligible to receive immediate provisional credit. If all these statements are true, the provisional credit accounting step is launched, including appropriate customer notification. The deposit account open date is > than 30 days ago If the number of prior dispute claims for the deposit account in the last 6 months <= 100 (this is set abnormally high due to limited demo data; expect customers to reduce this number to 0, 1 or 2.) If the deposit account current balance is >

61 Reverse Provisional Credit Reg E specifies that if you reverse provisional credit because you find the customer liable for example, you must notify the customer that you will be reversing the credit in 5 business days. The Reverse Provisional Credit action sends the notification to the customer about the reversal, and sets the SLA ReverseProvisionalCredit. On the 5th business day, the reversal accounting entry is completed with the completion notice sent to the customer. Multi-Dispute Claim Processing Multiple dispute claims can occur for a number of reasons, but are most prevalent with fraud. For example, a customer notices several unauthorized transactions because the account or card has been compromised. Smart Dispute allows processing for more than one dispute in a claim with several key pieces of functionality that can be extended in the field. Transaction Selection By selecting Dispute Multiple Transactions from the New drop-down menu, you can select more than one transaction from the transaction list on the Transaction Search screen 4-24

62 to create and add multiple disputes to the claim during case creation. The claim, which includes all selected disputes, is either a regular (sometimes called Billing) or fraud dispute. A claim cannot include a mix of fraud and non-fraud disputes. Once a dispute case is added to claim, it cannot be removed. The option to select a single transaction and create a single dispute for a claim remains. Qualify Fraud The QualifyFraud flow action presents several questions to qualify the customer s claim of fraud. Extend that flow action in the field for additional questions. Other Bulk Actions Flow actions that exist for single dispute processing have been brought to the claim level to allow for bulk action of multiple disputes. The following flow actions are available for bulk action processing as of this release: Duplicate Search Qualify Dispute Choose a Reason Code Answer Ancillary Questions Timeliness Processing Process Chargeback For multiple dispute case creation, you are brought to the Claim review harness where you can see the individual disputes listed for the claim and can select any number of disputes from the list for available bulk action. You can also add more disputes to the claim at this stage using the Add Multiple Disputes button, if needed. Validation is provided for Bulk Action, ensuring that assignments are processed in the same order as for single disputes. For example, if you try to select Qualify Dispute before Process Potential Duplicates, an error message is displayed. For screens that require individual decision for disputes being processed in bulk, rows are provided for each dispute that allow you to input information for each. For example, the Process Potential Duplicate screen provides a row for each dispute to decide whether it is a duplicate. Filters With debit processing, disputed transactions could have been processed over multiple networks, and therefore would have different network-specific reason codes and rules. Filters for Payment Network and Payment Channel are provided on the Claim review harness so you can filter the list of disputes accordingly. 4-25

63 Payment Channel is a configurable group of payment networks. You can then filter the disputes in a claim by that payment channel, to perform actions for only those selected disputes. In the framework, the debit payment channel is configured to include the Visa Signature, MC Signature, Visa Pin (Interlink), and MC Pin (Maestro.) Another option is to create a debit pin payment channel (Maestro and Interlink) and a debit pinless payment channel (Visa and MC.) Accounting Accounting at the claim level allows a single credit to the customer s account, while retaining necessary dispute-level accounting entries. The claim-level provisional credit action allows you to select one or more of the disputes in the claim to be included in the provisional credit calculation. The framework simulates presenting applicable fees so you can decide if any should also be included in the provisional credit entry. Integration with the deposit accounting system should occur at that step to find applicable fees. The total provisional credit to the customer is offset by a wash account called CustOffset. This step is an adjustment (not receivable) step. For each dispute included in the claim-level provisional credit step, a Receivable Open step is created in the background at the dispute level. With disputes subject to Reg E, reversing provisional credit requires sending a notice to the customer and setting an SLA for 5 days later. On the SLA deadline, the actual accounting entry to reverse the provisional credit will automatically fire. You can select other accounting entries, such as write-off and chargeback, as bulk actions from the claim level. The entries are completed at the individual dispute level, with no claim-level accounting. Correspondence New claim-level correspondence is available with a defined section to show properties for the individual disputes. Review the FraudAffidavitCorrespondence of type mail for an example of a claim-level document with a section PreviewSelCasesForFraudAffidavit included to define the dispute level properties. In addition, several claim-level notices are defined and specified in the claim-level accounting steps. Reg E at the Claim Level Reg E dates for each dispute are set after transaction selection, along with claim-level RegEPC, RegEFinal45 and RegEFinal90 dates. SLAs are set for each claim-level Reg E date, so that the claims can be managed from the user s worklist. If a set of disputes in a claim include no disputes with a Reg E final date of 90 days, then that property and SLA are not set. Customers who wish to manage Reg E dates by the earliest of the disputes RegEFinal dates can override the setting of the RegEFinal90 claim-level date if present. 4-26

64 Claim Summary Tab A new Claim Summary tab has been added to provide a visual status of the actions performed for disputes in the claim. The current list of actions that updates the Claim Summary tab includes: Qualify Fraud Aff Prov Credit Reason Code Chg Back Cust Liable Write Off Reverse PC PC Final You can extend or update this list in the field. Close Claim You can select the claim-level action Close Claim once all disputes have a resolved status. The action allows you to select the claim status from a drop-down list. 4-27

65 Chapter 5: Personalizing Smart Dispute This chapter describes some areas of Smart Dispute that you might want to modify and how to set up some functionality for your organization. The topics included in this chapter are: Using the New Currency Control Setting Up Correspondence Verification Modifying automatic Correspondence Generation Inserting Cardholder Supporting Documentation Requests Modifying the OnUs Decision Map Modifying Dispute Qualification Scripts Setting up Duplicate Scoring Rules Modifying SnapStart for Smart Dispute Using Dispute Types to Determine Work Objects Defining and Processing New Reason Codes Defining New Reason Codes Defining New Bank Identification Numbers (BINs) Using the New Currency Control PRPC introduced a new currency control to simplify the configuration options for the display of amount fields and their corresponding currencies. The new auto-generated control can display a selected currency using its symbol, code, full name, or ISO code. (However, for readability, the decimal separator and thousands separator come from the locale.) In addition, if the currency is displayed as a 3-digit code, it can show the ISO code before or after the amount (and optionally delimited by a forward slash): $ 1, , $ USD 1, , USD 1, /USD 5-1

66 Note: The main limitation of the previously standard pxcurrency is that it displayed the currency code, decimal separator, and so on, based upon the locale or by explicitly picking a different currency as the locale currency. All amount fields in Smart Dispute have been upgraded to use this new currency control. Please see the PDN article for more details on using this control in your application layer. Setting up Correspondence Verification Smart Dispute allows you to set up correspondence rules so that each item of correspondence, defined by a given rule, is routed to the manager s worklist for verification before it is sent to the recipient. Note: Before modifying a correspondence rule, make sure you have saved it to your ruleset. Do not modify the rule provided with Smart Dispute. To set up verification: 1. Open a correspondence rule from your ruleset. The Correspondence form appears, as shown below. 5-2

67 2. Select Verify from the After Create list on the Corr tab of the Correspondence rule form (Rule-Obj-Corr). Note: PRPC Online Help provides additional information for completing the After Create field as well as other fields on this form. Modifying Automatic Correspondence Generation Smart Dispute generates claim correspondence automatically based upon conditions defined either in an activity or in a flow. A PegaCard-Sd-Claim-.WaitToCloseCover service level starts the AllCoveredResolvedCheck activity that determines which Cover letters to send and at when to send them. This service level runs every 24 hours until all disputes (covered objects) have been resolved. 5-3

68 You can modify the steps in an activity to stop follow-up letters from being sent, and you can change the conditions that determine which letter is sent and its timing. Claim-level correspondence (Rule-Obj-Corr) records are in the PegaCard-Sd-Claim- class. The correspondence records used most often are listed below, along with the conditions that must be met for Smart Dispute to automatically generate a letter. AcknowledgeClaim generates the Claim Acknowledgement Letter Conditions: A letter is sent if a claim is still in an open status 24 hours after it was created (based on the SLA Deadline field) and contains at least one unresolved dispute. The letter is sent only once, when the service level runs for the first time. CardHolderAffidavitClaim generates the Claim Affidavit Letter Conditions: A letter is sent if a claim is still in an open status 24 hours after it was created (based on the SLA Deadline field), and the claim has at least one nonresolved dispute, and the claim reason is Fraud. The letter is sent only once, the first time the service level runs. ResearchingClaim generates the Claim Researching Letter (for example, Followup/Tickler letter) Conditions: A letter is sent if a claim is still in an open status five days after it was created, and the claim has at least one unresolved dispute. ResolvedClaim generates the Claim Resolved Letter Conditions: A letter is sent if a claim is still in an open status 24 hours after it was created (based on the SLA Deadline field), all disputes (covered work objects) have a resolved status, and the claim MultDisputes field is set to Y. The flow then finishes, and the claim status is set to Resolved-Completed. Removing the Claim Resolved Letter from the Flow If you do not want Smart Dispute to print and send the Claim Resolved Letter, you can modify the flow and remove the Resolution Correspondence section. To modify the NewWork flow: 1. Open the NewWork flow rule available in the PegaCard-Sd-Claim-class in the PegaCardSd ruleset. The Flow form appears displaying the NewWork flow as shown below. 5-4

69 5-5

70 2. Use the Save As option to save the flow rule to your application rule set and then remove the SendResolutionLetter utility shape. Removing the Acknowledgement, Affidavit, and Follow-up Letters The Acknowledgement, Affidavit, and Follow-Up letters are processed by the SLAOpenCoveredProcessing activity. If you remove the first three steps in this activity, then the letters are no longer processed automatically. To remove the letters: 1. Open the SLAOpenCoveredProcessing activity rule in the PegaCard-Sd-Claim- class in the PegaCardS ruleset. The Activity form appears, as shown below. 2. Use the Save As option to save the activity rule to your application ruleset and update the rule. 3. To remove a letter, click that row and then click Delete. 4. Click Save and close the form. Modifying Conditions for Letters to Be Sent You can change if and when cover letters are sent by modifying an activity. To modify the send correspondence conditions: 1. Open the SLAOpenCoveredProcessing activity rule in the PegaCard-Sd-Claim- class in the PegaCardS ruleset. The Activity form appears, as shown below. 5-6

71 2. Use the Save As option to save the activity rule, to your application ruleset to update the rule. 3. Modify the Call CorrNew steps based on the requirement. The detail information for that step appears, as shown below. 4. Replace the template identified in the CorrName field with the name of the correspondence template you want sent to the cardholder. 5. Click Save and close the form. 5-7

72 Inserting Cardholder Supporting Documentation Requests Some reason codes require the cardholder to supply documentation as part of the supporting documentation for a chargeback. When this occurs, Smart Dispute automatically creates an assignment pending receipt of the required documentation. In addition, you can also send a request for the document to the cardholder. You may wish to do so if the cardholder has indicated that they possess the required documents and you wish to confirm that they are sent. The following cardholder document types are predefined in Smart Dispute: Alternate Payment Document Cardholder letter Copy transaction receipt Copy transaction receipt missing imprint or signature To create a letter, make a copy of the document type rule and save it to your ruleset. Follow the steps below to add automatic correspondence to this process. To modify the document type rule: 1. Click the App Explorer tab. 2. Select Rule-PegaCard-DocType from the smart prompt. 5-8

73 3. Click the Rule-PegaCard-DocType class to view the document type instances. A list of document types appears. 5-9

74 4. Click the document type that you want to modify. The Document Type form appears, as shown below. 5. Use the Save As option of the rule in your application ruleset to update. 6. Click Save and close the form. Modifying the OnUs Decision Map The Bank Identification Number (BIN) indicates whether the dispute is OnUs. If the dispute is OnUs, then Smart Dispute creates an assignment and routes it to the OnUs workbasket. You may then process according to your business practices. 5-10

75 You use the OnUs decision map to identify your OnUs BIN numbers. If you do not wish special processing for OnUs BIN numbers, leave the default row. To modify the OnUs decision map rule: 1. Open the OnUs decision category Map rule in the PegaCard-Sd-Dispute- class in the PegaCardSd ruleset. A Map Value form appears, as shown below. 2. Use the Save As option to save the map rule into your ClassName-Sd-Disputeapplication class (where ClassName is your top-level class name) in your ruleset to update the rule. 3. On the Matrix tab, click in a field and then click Insert Row. 4. Add your BIN numbers and set their values to Y. 5. Click Save and close the form. Modifying Dispute Qualification Scripts Dispute Qualification scripts contain qualification questions and the TalkOff scripts. You can modify the TalkOff flow instance to make changes to the questions or the scripts. For example, you can move fraud-processing questions higher in the script so that those questions are asked earlier in the process. You can also add new questions. 5-11

76 To modify the TalkOff flow rule: 1. Open the ActionInvokeTalkOff section rule available in the PegaCard-Sd-Disputeclass in the PegaCardSd ruleset. A section rule form appears as shown below. 2. Use the Save As option of the section rule to your ClassName-Sd-Disputeapplication class (where ClassName is your top-level class name), in your application ruleset to update. 3. Click Save and close the form. Setting Up Duplicate Scoring Rules Smart Dispute can flag transactions as possible duplicates based on scoring rules that consider data elements such as the transaction amount, transaction date, account number, and acquirer reference number. Smart Dispute can also accept close matches two items dated within three business or calendar days, for example. You can also weight the two conditions so that an amount match is twice as important as a date match. When a dispute is entered, Smart Dispute uses the Duplicate search to locate possible duplicates. Rule-Search-Scoring identifies the critical fields for locating potential duplicates. For each field you identify, you set the conditions and a weighted average to be used when searching for duplicates. Smart Dispute tallies a score (weighted average) based on each matching field value and marks the case for review if the score exceeds the defined number. You can also set a threshold, which if not met, allows the case to continue through normal processing. To change a scoring definition: 1. Click the App Explorer tab. 5-12

77 2. Select Rule-PegaApp-Search-Scoring from the smart prompt. 3. Click the Rule-PegaApp-Search-Scoring class to list the instances of the rule. 5-13

78 4. Select the instance of DuplicateScore in the PegaCard-Sd-Dispute- class to display the Scoring Rule form, as shown below. 5. Use the Save As option of the rule to save to the ClassName-Sd-Dispute- application class (where ClassName is your top-level class name) in your ruleset to update the rule. 6. To change the comparison operation, select a value from the selection box. The choices are: Exact Match a string comparison; values (such as amounts, dates, or text) must match exactly. Range a numeric comparison; values (such as amounts) must match within a certain range. 5-14

79 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 business days. 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 a range of -1 to 1, a match occurs if the potential case has a value ± $1 from the amount of the case being searched. 8. Enter a value in the Weight field. The Weight values are arbitrary, but you must treat them as percentages that add up to To change the Minimum Confidence Threshold, enter a number from 1 to 100. For example, in Error! Reference source not found., the weighted average of the four conditions is 100. If you set the threshold to 75, the system automatically identifies the case as a duplicate and continues processing when three conditions are met. To add a new comparison, click Add Row; make sure any properties you add are valid and that you adjust the weighting appropriately. To delete a comparison, click Delete Row. 10. Click Save and close the form. Using Dispute Types to Determine Work Objects Smart Dispute is installed with predefined work object classes for transactions and disputes. If you modify or extend the existing workflows, create and use new work object classes. The DetermineWorkObjectChildClass data transform rule available in the PegaCard-Sd- Dispute-class in the PegaCardSd ruleset determines which class type of work object to create for each dispute. The InterchangeSourceID property is used as input to the following Map Value rules: AssociationDescMatrix determines the value of the InterchangeSourceDesc property. This property describes the association. TransDecTreeMatrix determines the value of the TransactionDecisionTree property. This property names a decision tree which is then executed to return the class type of the transaction page. As installed, Smart Dispute returns the following values: PegaCard-Interface-Transaction- (generic) PegaCard-Interface-Transaction-Association (where Association is an association type) 5-15

80 DisputeDecTreeMatrix determines the value of the DisputeDecisionTree property. This property names a decision tree which is then executed to return the class type of the dispute page. As installed, Smart Dispute returns the following values: PegaCardSd-Work-Dispute-<Wki> (generic) PegaCardSd-Work-Dispute-Association -International PegaCardSd-Work-Dispute-Association -US Modifying Existing Processing To modify the processing logic installed with the product: 1. Create the new work object class. 2. Modify the Decision Tree rules to return the new work object class for transactions or disputes. 3. Optionally, modify the InvokeAdvisorEnd Activity rule available in the PegaCard-Sd- Dispute-class in the PegaCardSd ruleset, if you create a new Reason Code Advisor class. 4. Optionally, if they are the closest models to use, modify the GenericTransDT and GenericDisputeDT Decision Tree rules available in the PegaCard-Sd-Dispute-class in PegaCardSd ruleset, which determine the transaction page and dispute page, respectively, for generic transactions. In the following example, existing processing is modified to process transactions for Japanese Card cards. The new work object class created is PegaCardSd-Work-Dispute-Card-Japan. To modify the decision tree: 1. Open the VisaDisputeDT decision tree rule available in the PegaCard-Sd-Disputeclass from the PegaCardSd ruleset. The Decision Tree form appears, as shown below. The rule is in a locked ruleset, so you must save it to your own ruleset before you can modify it. 5-16

81 2. Click Save As and select the ClassName-Sd-Dispute-application class (where ClassName is your top-level class name), in your ruleset to modify it. 3. Edit the decision tree to include logic to determine whether the transaction originated in Japan. In this example, the string returned by the decision tree would be PegaCardSd- Work-Dispute-Card-Japan. 4. Click Save and close the form. Creating a New Association To support a new association: 1. Create new work object classes for transactions and disputes. 5-17

82 2. Modify the Map Value rules to refer to new decision trees. 3. Create new Decision Tree rules to return the new work object classes. 4. Modify the InvokeAdvisorStart and InvokeAdvisorEnd Activity rule to use the new Reason Code Advisor class. 5. Optionally, if they are the closest models to use, modify the GenericTransDT and GenericDisputeDT Decision Tree rules, which determine the transaction page and dispute page, respectively, for generic transactions. In the following example, you want to accept a new credit card, CardMan, with an interchange source ID of 13. Disputes originating from Canada are to be handled specially. The following new work object classes are created: PegaCard-Interface-Transactions-CardMan PegaCardSd-Work-Dispute-CardMan PegaCardSd-Work-Dispute-CardMan-Canada To modify the Map Value rules: 1. Open AssociationDescMatrix Map Value rule available in the PegaCard-Sd-Disputeclass in the PegaCardSd ruleset. The Map Value form appears, as shown below. The rule is in a locked ruleset, so you must save it to your own ruleset before you can modify it. 5-18

83 2. Click Save As and select the ClassName-Sd-Dispute-application class (where ClassName is your top-level class name), in your ruleset to modify it. 3. Edit the map value so that the Interchange Source ID 13 maps to CardMan Credit Cards. 4. When you finish, click Save and close the form. 5. Repeats steps 3 to 7 for the TransDecTreeMatrix Map Value rule, so that the Interchange Source ID 13 maps to CardManTransDT. 6. Repeats steps 3 to 7 for the DisputeDecTreeMatrix Map Value rule, so that the Interchange Source ID 13 maps to CardManDisputeDT. To create decision tree rules: 1. Click the Records Explorer tab. 2. Expand the Decision category and click DecisionTree to display a list of decision trees. 5-19

84 3. Select VisaDisputeDT, an existing decision tree to be used as a template. The Decision Tree form appears, as shown below. The rule is in a locked ruleset, so you must save it to your own ruleset before you can modify it. 5-20

85 4. Click Save As on the decision tree rule form and save to the ClassName-Sd-Disputeapplication class (where ClassName is your top-level class name), rename the decision tree CardManTransDT, in your ruleset to modify it. 5. Edit the decision tree to always return the string PegaCard-Interface-Transactions- CardMan. 6. When you finish, click Save and close the form. 7. Repeats steps 3 to 7 to create the Decision Tree rule CardManDisputeDT, so that the rule returns the PegaCardSd-Work-Dispute-CardMan-Canada string if the cardholder is Canadian, and otherwise, the PegaCardSd-Work-Dispute-CardMan string. 5-21

86 Defining and Processing New Reason Codes A Reason Code rule represents the chargeback requirements for a reason code or a condition code pair. If you modify or extend the existing reason-code processing, you may need to create new Reason Code rules. Decision Tree rules determine how reason codes are processed for each association. If you create a new reason code, you must modify the appropriate decision trees accordingly. To define and process a new reason code: 1. Create the new Reason Code rule. 2. If necessary, create new Ancillary Question rules to support the new code. 3. Modify the Decision Tree rules to process the new reason code. To create a new reason code: 1. Click the App Explorer tab. 2. Select Rule-PegaCard-ReasonCode from the smart prompt. 3. Click on the class Rule-PegaCard-ReasonCode to display a list of reason codes. 4. Click New. The New form appears. 5. Select the appropriate class name from the Class Name list, enter the name of the reason code in the Reason Code field, enter the appropriate condition code in the Condition Code field, and select the appropriate ruleset from the Name selection box. 6. Click Create. The Reason Code form appears, as shown below. 5-22

87 7. Complete the fields of the tabs as described in the following table. 8. When you finish, click Save and close the form. Field Short Description Timeframes Tab Primary Timeframe Primary Applies To Primary Condition Secondary Timeframe Secondary Applies To Secondary Condition Documents Tab Inbound Documents Label Description Required. Description of the reason code. A Reason Code rule has two timeframes: primary and secondary. A primary timeframe is the time period in which a chargeback must be initiated. (The timeframe that has the latest expiration date is used as the dispute timeframe.) A secondary timeframe lets an initiated claim continue after the initial timeframe has elapsed (often the date a retrieval request was completed). Number of days in which the dispute is still valid. This date should be checked by a CheckTimeliness activity. Property to which to apply the primary timeframe. When rule defined on the same class as the Reason Code. Number of days within which the initiated dispute is still valid. This date should be checked by a CheckTimeliness activity. Property to which to apply the secondary timeframe. When rule defined on the same class as the Reason Code. Lists supporting documents and the condition that makes them required. To add a document to the list, click either Add or Insert; to remove a document from the list, click Delete. Simple label for the inbound document. 5-23

88 Field Inbound Documents Property Inbound Documents Required? Inbound Documents Type Inbound Documents Criteria Outbound Documents Label Outbound Documents Property Outbound Documents Required? Outbound Documents Type Outbound Documents Criteria Document Indicator Description Property that signifies that this inbound document is attached to the case. When rule that determines if the inbound document is really necessary. Type of inbound document (instance of Rule-PegaCard-ReasonCode- DocType). List of criteria displayed to the user when attaching the inbound document to the case. The document should contain the information in the criteria. Simple label for the outbound document. Property that signifies that this outbound document is attached to the case. When rule that determines if the outbound document is really necessary. Type of outbound document (instance of Rule-PegaCard-ReasonCode- DocType). List of criteria that should be displayed to the user when attaching the outbound document to the case. The document should contain the information in the criteria. One of the following: 0 No supporting documentation provided 1 Supporting documentation is to follow 2 Invalid Reference Number Documentation Not Required/Received 3 Incompatible/Invalid Reference Number Documentation Required 4 Supporting Documentation Not Received Details Tab Ancillary Questions Message Text Default case to fraud? Next Tab Contains a list of ancillary questions. This is a list of keys to instances of Rule-PegaCard-ReasonCode-Question. Question displayed to the user once a reason code is chosen. The answer to this question may also control next-step processing. To add a question to the list, click Add. Key to an instance of Rule-Obj-HTML or Rule-HTML-Fragment defined on the class the reason code is defined on or Select if this is a fraud-related reason code. Lists those things that may need to be done after the ancillary questions are answered. 5-24

89 Field Retrieval Required? Retrieval Flow Chargeback Flow Second First Chargeback? Chargeback Amount Limitation Limits Tab ReasonCode Limitations History Tab Description Enter true, false, or a When rule that controls whether or not a retrieval request is required. Flow rule to be run for the retrieval request. Flow rule that contains the chargeback processing. Select if this reason code allows second first chargebacks. Activity that calculates acceptable amount for a chargeback. Limits the reason code. To add a limitation, click the Append Row button. Enter a detailed description of the reason code and information on how it is used. To review the Save history, click History Details. To create a new ancillary question: 1. Click the App Explorer tab. 2. Select the PegaCard-ReasonCode-Question class from smart prompt. Click on the class to list ancillary questions. 3. Click Create on the developer toolbar. A New form appears. 4. Select the appropriate class name from the Class Name field, enter the name of the question in the Question ID field, and select the appropriate ruleset from the Name selection box. 5. Click Create. The Ancillary Question form appears, as shown below. 5-25

90 6. Complete the fields of the tabs as described in the table below. 7. When you finish, click Save and close the form. Field Details Tab Display HTML Category Validation Rule Control Tab Whens History Tab Description Lists the Display HTML, Category, and Validation rules. Rule containing text of the question that is displayed to the user for customer query. Type of question or grouping to which a question is related. Sets the requirements for the question, the properties that would be validated against, and whether or not they are required. Lists When rules that would be applied to the ancillary question. When rule defined on the same class as the Ancillary Question. Enter a detailed description of the ancillary question and information on how it is used. To review the Save history, click History Details. Defining New Reason Code Advisor Categories Based on the communication source (issuer or cardholder) and certain dispute details, the Reason Code Advisor begins the line of questioning from a set of six categories: Disputes concerning goods and services Authorization issues Processing errors and cardholder-did-not-recognize issues Authorization/fraud issues Fraud issues Non-receipt of information If you modify or extend the existing reason-code processing, you may need to modify or create categories to match. Categories are defined in an HTML Property rule (an instance of Rule-HTML-Property) named Category. To create a new category: 1. Click the Records Explorer tab. 2. Select User Interface > Control. 3. Search with stream name Category. 5-26

91 A list of control rule appears. The ruleset location varies according to the associations that have been installed. 4. Select the Category instance. The HTML Property form appears, as shown below. The rule is in a locked ruleset, so you must save it to your own ruleset before you can modify it. 5. Click Save As. 6. In the Save As form, select your ruleset from the selection box, and then click Save As. The activity is saved into your ruleset, and you can now modify it. 7. Edit the HTML code as necessary to include the new category. 8. When you finish, click Save and close the form. Defining New Bank Identification Numbers (BINs) If 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 of Rule-Obj-Model), where nnnnnn is the issuer number. To define a new BIN: 1. Click the Records Explorer tab. 5-27

92 2. Select Data Model > Data Transform to display a list of Data Transform rules. 3. Filter the list where the Name includes BIN, and select a Data Transform rule. The Data Transform form appears, as shown below. The rule is in a locked ruleset, so you must save it to your own ruleset before you can modify it. 4. Click Save As. The Save As form appears. 5. Enter the new name in the Model Name field, select your ruleset from the selection box, and then click Save As. The model is saved into your ruleset, and you can now modify it. 6. Edit the list of properties as necessary to define the new issuer. 7. When you finish, click Save and close the form. 5-28

93 Chapter 6: Working with Accounting Functions The procedures in this chapter describe how to configure the Smart Dispute accounting functions. The topics covered in this chapter include: Setting up account types Setting up accounting party data Defining the Chart of Accounts Setting up payment types Accounting step rules Setting up verification levels Modifying the provisional credit decision tree Setting up automatic write-off criteria Setting up cut-off times and the calendar Understanding how multi-currency works Setting Up Account Types Smart Dispute uses internal accounts to track accounting transactions. Internal accounts are defined in the PegaAcct-Party-InternalAccount class. You can use the sample internal accounts defined in the PegaAcct-Party-InternalAccount class, and you can create your own internal accounts in that class. Internal accounts are referenced in the Chart of Accounts. Defining the Chart of Accounts Smart Dispute s sample Chart of Accounts is the FinChartofAccts Map Value rule in the PegaAcct-Work class. This Chart of Accounts lets you specify general-ledger accounts that are associated with internal accounts within the product. You can set up a Chart of Accounts that refers to the internal accounts for your organization. 6-1

94 The following figure shows the Map Value form. 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 not change these values unless you have overridden all step rules that refer to them. The Bank Number column shows the keys of internal accounts if you are running in a multi-bank environment. (Bank Number is synonymous with BIN number. You can have multiple banks with multiple accounts.) 6-2

95 Setting up Payment Types A payment type is associated with a debit or credit transaction in an accounting step. The payment type can determine the following: Whether documents or automatic advices are generated Whether an accounting cutoff time is enforced. The Rule-PegaAcct-Financial-PaymentType rule defines payment types. The payment type is associated with a transaction in step rules. If your organization s transactions require documents different than the ones referenced in the supplied payment-type rules, or if you require different cutoff times, then create the Rule-Obj-Corr and Rule-PegaAcct-Financial- Cutoff rules first, and then copy the payment-type rule with the same name to your ruleset. If you require new payment types, create your own by copying and updating an existing one, and then updating the step rules 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 two of the key properties (Stream Name and Corr Type), to which the system implicitly adds the work object class. Select the Required check box to generate a document for all transactions that use this payment type. If you do not select this check box, the document is not generated for automatic processing, but you have the option to generate it during manual processing. Accounting Step Rules Accounting step rules define which debit and credit transactions make up an accounting entry. There are three 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 ways to create the information in an accounting step. The key is made up of the work object class for which accounting is being processed, an accounting action (different for a suspense transactions versus an adjustment transaction), and a Type that specifies a name for the particular rule. The following figure shows the Step tab of the Adjustment Rule window for the CrCardHolder instance in the PegaCard-Sd-Dispute- class. 6-3

96 The following shows the Transactions tab for the same instance. Scroll from left to right to see all of the fields. These fields, and their use in creating new step rules, are described in detail in the following topics. Fields on the Adjustment Rule Form The following table describes the fields in the Adjustment Rule form. Field Short Description Description Required. Short description of the rule. This value is displayed during manual accounting in the list of step rules the user can select. Step Tab Class of the Step The class of the page that holds the Step data. Specify a Rule-Objclass name that is a concrete class and is a child of the PegaAcct- Step- class. 6-4

97 Field Activity for Verification Flow Model to create Step Validate Activity Likelihood Description An activity at the class of the step that calls a verification flow. If blank, the system automatically passes the accounting through without verification. One activity delivered with the product specifies a verification flow based on amount values. The activity lets you do verification up to four levels, which can be used based on the amount of the 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 step rules in the product do not use a model. Reserved for future use. An integer between 0 and 100 that is used to preselect the most likely step rule (the one with the highest number) during the manual flow actions that create accounting steps. Transactions Tab Group Specifies whether this accounting transaction is part of a group of transactions such that only one transaction in the group is used when the accounting is created. In manual processing, the user chooses a transaction from the group (the Label property is displayed in a selection box so that only one transaction can be chosen). In automatic processing, the first transaction in the group is selected automatically so the transaction order is significant. Note that Smart Dispute does not use groups because there is a single internal account for Receivable, Write-Off, and so on. Label DR / CR Role Txn Class Appears in the window during manual accounting creation flow actions to indicate the name of the transaction. Indicates whether the transaction is a Debit or a Credit. The rule requires that debits are listed before credits for consistency. The order of the transactions in the rule is the order in which they are displayed during manual accounting creation flow actions. A unique string identifier for each transaction in this step. Its value is placed into a property named Role in the transaction of the step, and can be used to find or report on the transaction. The class of the page that holds the transaction data. Select a Rule- Obj-Class name that is a concrete child class of PegaAcct-Txn-. 6-5

98 Field Pymt Type Default Account From Description Name of the Rule-PegaAcct-Financial-PaymentType rule to use for this transaction. The payment type rule associates correspondence with the transaction. Specifies how to determine the account name and number for this transaction: Party: Take from the Party role in the work object. (The role is specified in the DefaultAccountValue property.) Chart of Accounts: Take from a specified internal account. The value of the DefaultAccountValue property is used in a lookup to a Map Value named FinChartOfAccts at the class of the work object. This process returns a key to a Data Party record. A second Map Value is used at the class of the work object to determine the actual party class in which to look up this key. The system finds the party class by looking up the InternalAccount value in the Map Value named WorkPoolClasses. Account From Value Protect Account? Default Amount From Specifies a party role if the Default Account From value is Party. Specifies an internal account name (as defined in the map value FinChartOfAccts) if the Default Account From value is Chart of Accounts. Select to prevent input in the Account Name and Number fields of the user interface during manual accounting creation. If not selected, users can modify these values during manual accounting creation. Specifies where to acquire the amount value for this transaction: Property: use the property value specified in the DefaultAmountValue property. Literal: use the value of the DefaultAmountValue property. Amount From Value Specifies a property reference if DefaultAmountFrom is Property. A reference can be any fully qualified property reference from any page. If the property reference is not dot qualified, then Smart Dispute assumes that the property is on the top level of the work object page. Specifies an actual amount number value if Default Amount From is Literal. Do not use quotation marks, $, or commas (for example, if the value is one thousand, enter , and not any of the following: $1, or $ or ). 6-6

99 Field Protect Amount? Description Select this check box to prevent input in the Amount field of the user interface during manual accounting creation. If not selected, users can modify this value during manual accounting creation. Security Tab Name Class When Name History Tab Optional. Enter the name(s) of any named privileges where access to the privilege allows this step to be executed. Optional. Enter the class of privileges you specify in this window. Optional. Enter a Rule-Obj-When rule that equal true for this step to be executed. Most Smart Dispute step rules use When rules to allow step access only if the referenced Party Role exists in the work object. Full description of the adjustment rule and information on its usage. Creating an Accounting Step Rule The accounting straight-through processing (automatic) flows and flow actions use a specific action of a rule class, such as Open Payable (Open action of the Payable rule) or Adjustment (Adjust action of the Adjustment rule). Smart Dispute supports Adjust and WriteOff adjustment actions and Open, Close, Lower, and WriteOff suspense actions. Automatic flows require a parameter specifying the appropriate rule to use. The parameter specifies the Type 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 every step rule that the flow action can use, including security validation. By default, Smart Dispute uses the transaction information from the rule with the highest likelihood and lets you select any other valid step rules from a list of rules and their short descriptions. 6-7

100 The standard straight-through processing flows (defined in PegaAcct-Work) are: ReceivableOpenSTP ReceivableWriteOffSTP AdjustmentSTP ReceivableCloseSTP PayableOpenSTP AdjustmentWriteOffSTP ReceivableLowerSTP PayableCloseSTP To modify a step rule, save it to your ruleset. Reasons to modify rules include the following: To add verification to a step. To update payment types if you create new payment types. To change the Protect field to let users modify information at creation. To change account default information to use different party roles. To use different internal accounts if you add accounts to the Chart of Accounts. When creating new step rules, either update flows to call the rules or add rules to give users more choices than the automatic flows provide. In the latter case, the Likelihood value becomes significant. Setting up Verification Levels Your organization can have a policy that adjustments above a certain amount must be verified by a manager. For example, you can choose not to require verification for credits below $100, but require a senior review and verification for accounting credits of more than $5,000. As initially installed, no accounting steps require verification; however, Smart Dispute supports up to three levels of verification based on value. The verification levels are the number of times an item must be verified. The privileges assigned to users determine the top level at which a user can verify. No user can verify an accounting step more than once, regardless of the user s privileges. To include verification in your business flows, you must configure step rules to specify a value of FinVerifyByAmount in the Activity for Verification Flow field on the Step tab. This activity uses the FinVerificationFlowByAmount MapValue, in the PegaAcct-Step class, to determine the verification levels based on amount thresholds. If you review these values and find them suitable for your organization, you can use the rule as is. Cutoff Times Your organization can define a time of day after which completed transactions must be posted to the next business day. A cutoff rule named Default, defined by the Rule-PegaAcct- Financial-Cutoff rule, uses a warning time and a cutoff time such that all times of day within the rule are not past cutoff. 6-8

101 If your organization requires different cutoff times for different payment types, you must create new cutoff rules in your ruleset and update your Rule-PegaAcct-Financial- PaymentType rules to reference them. Any number of payment types can refer to the same cutoff rule. For example, if your card processing system has a settlement deadline, then the Settlement Rule-PegaAcct-Financial-Cutoff rule can define the cutoff times. Each payment type sent to the card processing system 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 Settlement rule. All payment types that reference the Settlement rule are automatically subject to the new cutoff schedule. The warning and cutoff times in the rule affect only the user interface. When processing an accounting step that has not yet been posted (at creation, verification, or held in cutoff), you see a yellow clock icon next to any transaction that is past its warning time and a red clock next to any transaction that is past its cutoff time. New Suspense Accounting In this release, you can more finely control suspense accounting. In prior releases, the sum total of an open suspense transaction was written to the Outstanding and Suspense Balance of the work item on pyworkpage. This was true even if the Open suspense step contained non-suspense transactions. For example, if an Open step contains the following: DR Suspense Receivable DR Fee Reversal CR Customer Account 150/USD 35/USD 185/USD Then the Suspense and outstanding balance would be written as 185/USD. Similarly, raises would increase this balance, while lowers, closes, and write-offs would lower the balance, eventually to 0/USD. In previous releases, customers tended to split the steps into a receivable open for the 150/USD and a fee adjustment for the 35/USD. This was done to avoid writing off the 35/USD fee reversal, and it assumed full recovery of the 150/USD receivable. This approach had the potential of resulting in two separate credits to the customer. Starting in release 7.12, you can optionally create one accounting step that correctly accounts for the suspense balances and provides a single credit to the customer. Using the same open accounting step example: 6-9

102 DR Suspense Receivable DR Fee Reversal CR Customer Account 150/USD 35/USD 185/USD Using this option, the Suspense and outstanding balance is written as 150/USD. Similarly, only suspense raises would increase this balance, while suspense lowers, closes, and write-offs would lower this balance, eventually to 0/USD. To take advantage of this new method for suspense accounting, you must add some configuration elements: 1. To enable the new method for suspense accounting, configure the dynamic system setting as follows: a. Data-Admin-System-Settings b. Owning Rule Set PegaAAccounting c. Purpose: NewSuspenseAccounting d. Value: true. If false or blank, the feature is disabled. 2. Update the internal accounts used by the FinChartofAccts instances of PegaAcct- Party-InternalAccount to add a value for a General Ledger Account Type. A value of suspense marks the account as available for New Suspense Accounting. 6-10

103 3. Create an Open Accounting step rule that contains at least one account with a GL type of Suspense and one that contains a GL type not equal to Suspense. 4. Execute the step and observe the treatment of the outstanding and suspense balances. The expected behavior is that these balances should match the total of the transactions that match a suspense GL type. Cut-off Times and the Calendar Before a step can be posted during accounting cutoff processing, all transactions in the step are checked against the cutoff time in the Rule-PegaAcct-Financial-Cutoff rule specified by the Rule-PegaAcct-Financial-PaymentType. Depending on the type of transaction, the Rule- PegaAcct-Financial-PaymentType specified in one of the following step rules is checked: Rule-PegaAcct-Financial-Adjustment Rule-PegaAcct-Financial-Payable 6-11

104 Rule-PegaAcct-Financial-Receivable Before using the specified cutoff time, the system checks the calendar to check whether the processing occurs on a business day. If it is not a business day, the transaction is automatically held for cutoff and posted on the next business day. The steps held for posting on the next business day are re-released for 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. The Default calendar, used in all areas of the product, is specified in the FinCutoffCalendar map value rule in the Rule-PegaAcct-Financial-Cutoff class. You can create an additional calendar if your organization 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 a date not found in any calendar instance, it assumes that the date is a non-business day. Setting up Calendars Smart Dispute uses calendars to determine which dates are business days as well as the hours of operations on those days. Non-business days include weekends and holidays. Calendars affect the following activities: Service level rules can specify goal and deadline times in business days Accounting can only be posted on business days Calendars are stored as instances of the Data-Admin-Calendar class. Calendars must be named Default and use a start date of January 1 in the format yyyymmdd. Update or create instances for each year to define business days and local holidays. Adjusting Automatic Chargeback When the rules determine that qualifications have been met for chargeback, Smart Dispute determines if an automatic chargeback should be initiated. The DetermineAutomation activity enables you to toggle between manual and automatic. Understanding How Multi-currency Works When Smart Dispute is installed, it provides functionality that supports the capture, conversion, tracking, and reporting of disputes and their related currency. This functionality requires the use of properties, conversion rates, checks and balance, and accounting. Properties and Multi-Currency Smart Dispute manages multiple currencies by capturing individual property values for the currency and the currency description for groups of amount properties. 6-12

105 In Smart Dispute, currency is defined as a numeric value (for example, 840), and currency description is defined as the java class currency qualifier (for example, USD). When necessary, the currency value is passed through a map to determine the java class descriptor for this currency. This java class descriptor becomes the currency qualifier for the amount property that allows Smart Dispute to display the amount with the correct currency symbol. For more information on currency qualifiers and set-up, see the Application Developer Help or the PDN. The following table shows the major properties that Smart Dispute uses to track and manage currency functionality throughout the lifecycle of the dispute. Property Currency Property Currency Description Property DisputeAmount BillingCurrency PostedAmount PostedCurrency PostedCurrencyDesc SettlementAmount SettlementCurrency SettlementCurrencyDesc TransactionAmount TransactionCurrency TransactionCurrencyDesc AuthorizationAmount AuthorizationCurrency AuthorizationCurrency Desc BaseAmount BaseCurrency BaseCurrency DefaultCurrency DefaultCurrency BillingCurrency BillingCurrency BinCurrency BinCurrency BillingCurrencybyBIN BillingCurrencybyBIN CommonCurrencyConRate BasicCurrencyConRate Most of these properties directly relate to the disputed transaction and are therefore stored externally. The table below provides a list of the properties, the clipboard page on which they are stored, and the source of the data (that is, where the data is coming from). Property Clipboard Page Source DisputeAmount pyworkpage (pywp) PostedAmount PostedAmount pywp.accounttransaction Table:Pcd_Transactions PostedCurrency pywp.accounttransaction Table:Pcd_Transactions PostedCurrencyDesc pywp.accounttransaction Mapped Value SettlementAmount pywp.accounttransaction Table:Pcd_Transactions SettlementCurrency pywp.accounttransaction Table:Pcd_Transactions SettlementCurrency Desc pywp.accounttransaction Map Value TransactionAmount pywp.accounttransaction P Table:Pcd_Transactions TransactionCurrency pywp.accounttransaction Table:Pcd_Transactions TransactionCurrencyDesc pywp.accounttransaction Mapped Value AuthorizationAmount pywp.accounttransaction Table:Pcd_Transactions AuthorizationCurrencyCode pywp.accounttransaction Table:Pcd_Transactions 6-13

106 Property Clipboard Page Source AuthorizationCurrency Desc pywp.accounttransaction Mapped Value BasicCurrencyConRate pyworkpage Table:Pcd_Transactions BaseAmount pyworkpage Table:Pcd_Transactions BaseCurrency pyworkpage Table:Pcd_Transactions BillingCurrency pyworkpage Posted Currency BillingCurrencyByBIN pyworkpage Mapped Value BillingCurrencyDesc pyworkpage PostedCurrencyDesc DefaultCurrency pyworkpage Table:Pcd_Transactions CommonCurrencyConRate pyworkpage BasicCurrencyConRate Displaying and Tracking Currency Smart Dispute uses properties to help track and manage currencies as a dispute moves through the system. The example below uses the TransactionAmount and TransactionCurrency properties to explain how the currency is tracked and managed. Example: Smart Dispute retrieves TransactionAmount and TransactionCurrency from the disputed transaction record. The transaction amount is 425 Euros and the transaction currency value is 978. Smart Dispute passes the currency value to Rule-> Obj- > MapValue- > CurrencyType to determine the java class name of the currency (EUR in this case), and then writes the value to TranactionCurrencyDesc. Conversion Rates Smart Dispute assumes that the conversion rate used to convert a transaction amount into the posting amount is provided in the disputed transaction record. For example a transaction of 425 Euros, with a posted amount of 850 US, has a currency conversion rate of Smart Dispute assumes that the chargeback amount is of the same currency type as the posting amount, with the associations managing the exchange of currencies between the Issuer and Cardholder and the Acquirer and Merchant. You can adjust the dispute amount when entering the dispute details. Any adjustment to the dispute amount is automatically adjusted by the DisputeTransactionAmount property, using the currency conversion rate provided. This property and its currency can then be passed to the association during the chargeback. The following figure shows the original Dispute Amount of USD, the conversion rate of.738, and the disputed transaction amount of EUR. 6-14

107 The following figure shows the new Dispute amount, based on an update to the Dispute transaction amount. 6-15

108 The following figure shows how Smart Dispute passes the change through to process the chargeback. Verifying Posting Currency Smart Dispute provides posting verification as part of the multi-currency functionality. Smart Dispute supports a single issuing bank managing multiple Association (Visa, MasterCard, Discover, and so on) Bank Issuer Numbers (BINs). A BIN is the first 6 digits of the account number. It is the key to association processing (transactions, Chargebacks and so on). In Smart Dispute, each of the Issuing BINs can have one default for each of the billing currencies. As a result, a global credit card issuer could have BINS denominated in USD, GBP, EUR, JPY, and so on. 6-16

109 Smart Dispute checks to make sure that the posting currency of the transaction is equal to the default currency of the Issuing BIN. The dispute is flagged as an error if these values do not match. The default Issuing BIN currencies are set up using the decision tree (PegaCard- > Sd- > Dispute-, and then selecting the CheckCurrency Decision Tree), as shown below. 6-17

110 Accounting During accounting processing, Smart Dispute keeps the currency value of the amount involved in the accounting transaction and stores it along with other accounting details. Smart Dispute stores accounting data in a Database Table called PAF_INDEX_TXN. This data is stored in the AmountCurrency and BaseCurrency columns. See Chapter 7, Smart Dispute - FSIF Integration Layer for more information about this database table. 6-18

111 Chapter 7: Smart Dispute - FSIF Integration Layer Prior to Smart Dispute 7.x The Smart Dispute application layer contains PegaApp/PegaAppFin rulesets. The Smart Dispute application fetches the Customer, Account, and Transaction data from the database directly via connect-sql rules. Starting in Smart Dispute 7.x The Financial Services Industry Foundation (FSIF) layer rule sets are included in the application. Parent class inheritance in the Smart Dispute application is modified for the Smart Dispute classes to PegaAcct-Work. The application retrieves Customer, Account, and Transaction details from the FSIF layer using Data pages. 7-1

112 Smart Dispute 6.3 Application Ruleset Stack The SmartDispute_Base 6.3 application had PegaApp/PegaAppFin rulesets. Figure 1: Smart Dispute 6.3 ruleset stack 7-2

113 Smart Dispute 7.x Application Ruleset Stack The following figure shows how the FSIF integration layer fits into the Smart Dispute application design starting in Smart Dispute 7.x. Figure 2: FSIF Integration Layer in Smart Dispute 7.x Starting in Smart Dispute 7.x, the Built on Application is changed to PegaFSIF for SmartDispute_Base and it includes the PegaFSUI and PegaFWUI rulesets. Figure 3: Smart Dispute 7.x application ruleset stack 7-3

114 Figure 4: Application ruleset of PegaFSIF Pega-provided rules in the PegaApp/PegaAppFin ruleset are available in the PegaFSIF application rulesets. Rules that refer to the PegaApp class are modified to refer to the PegaAcct class. Figure 5: Modified Class name 7-4

115 The following table shows the property rules and the difference in content. Previously, these properties were located in PegaApp-Interface-Account (PegaCard), but now they are located in PegaFS-Data-Account-Card (PegaFS). Property Name CashBalance FeeBalanceTransfers MinimumPaymentTerms GracePeriod Last12MonthsLateOverlimitcount Last12MonthsLatePaymentscount Last12MonthsNSFcount FeeCashAdvance FeePurchases CashAPR CreditLine CreditLineAvailable FeeAnnual FeeInsufficientFunds FeeLate FeeOverlimit MerchandiseAPR Last12MthsLatePaymentFeeTotal Last12MthsNSFFeeTotal Last12MthsOverlimitFeeTotal MerchBalance Difference in Content Property Type is Text in PegaApp and Decimal in FS class Property Type is Text in PegaApp and Decimal in FS class Property Type is Text in PegaApp and Decimal in FS class Property Type is Text in PegaApp and Integer in FS class Property Type is Text in PegaApp and Integer in FS class Property Type is Text in PegaApp and Integer in FS class Property Type is Text in PegaApp and Integer in FS class Difference in UI Control and Property Qualifiers Difference in UI Control and Property Qualifiers Difference in UI Control, Expected Length, Property Qualifiers Difference in UI Control, Expected Length, Property Qualifiers Difference in UI Control, Expected Length, Property Qualifiers Difference in UI Control, Expected Length, Property Qualifiers Difference in UI Control, Expected Length, Property Qualifiers Difference in UI Control, Expected Length, Property Qualifiers Difference in UI Control, Expected Length, Property Qualifiers Difference in UI Control, Expected Length, Property Qualifiers Rule not exist in PegaFS-Data-Account-Card class Rule not exist in PegaFS-Data-Account-Card class Rule not exist in PegaFS-Data-Account-Card class The Property is replaced by (MerchandiseBalance) 7-5

116 The following table contains the list of PegaApp built-in functions that have been replaced with Pega-provided Pega 7 or FSIF equivalents. PegaApp Function PegaAppFin_default.subtractAmounts PegaAppFin_default.addAmounts PegaAppFin_Date.addToDate PegaAppFin_Date.before Current Function Pegaaccounting_pegaaccounting.subtractAmounts PegaAccounting_PegaAccounting.addAmounts PegaCardSd_Date_addToDate PegaCardSd_Date_before Modified the Parent Class for Smart Dispute Classes The parent class of Smart Dispute classes was changed from PegaApp-Work to PegaAcct-Work class. For example, the Parent Class of PegaCard-Sd-Dispute was changed to to PegaAcct-Work. Figure 6: Parent Class 7-6

117 Retrieve Customer, Account, and Transaction details from the FSIF layer The FSIF Data Model includes a set of reusable data pages and auto-populated properties. These features make it easy for FSIF consumers to retrieve data and navigate through the relationships between the various Data Model clipboard pages. Use the FSIF data pages to fetch the details. Figure 7: FSIF Data page reference in a data transform The Acquirer Connect-SQL rules are replaced with FSIF data pages. The following table contains the Connect-SQL rules and their equivalent FSIF data pages. Connect SQL getmerchantdbaname,getmerchantdata getfloorlimit GetChargeBackDetails GetAcquirerCaseDetails GetCurrPCDTransactionReport AppGetTransactionARN GetRetrievalRequestDetails Data Pages D_CreditCardTransactionSummary, D_CreditCardTransactionOpen D_CreditCardTransactionSummary, D_CreditCardTransactionOpen D_GetAllPcdChargeBackDetails D_CheckForAcquirerCase D_CreditCardTransactionSummary, D_CreditCardTransactionOpen D_CreditCardTransactionSummary D_GetAllPcdChargeBackDetails 7-7

118 In Smart Dispute Issuer, data pages are replaced with the FSIF data pages. The following table shows the Smart Dispute data pages and their equivalent FSIF data pages. Smart Dispute Data Pages D_GetAllAccountsByDepositAcctNbr D_GetCustAcctRelationData D_GetCustData D_GetAccountData D_GetAccountInfoByDepositAcctNbr D_GetAccountDataForAppReadAcctInfo D_CardGetTransactionDetail D_GetAllAccountTransactionDetailsByAcqRefNum D_GetAllAccountTransactionDetails D_CardGetMerchantDetails FSIF Data Pages D_CreditCardAccountSummary, D_AccountOpen D_AccountXRefList D_CustomerOpen D_CreditCardAccountSummary, D_AccountOpen D_CreditCardAccountSummary, D_AccountOpen D_CreditCardAccountSummary, D_AccountOpen D_CreditCardTransactionSummary, D_CreditCardTransactionOpen D_CreditCardTransactionSummary D_CreditCardTransactionSummary, D_CreditCardTransactionOpen D_CreditCardTransactionSummary, D_CreditCardTransactionOpen 7-8

119 Example To understand the design, consider the data page D_CreditCardAccountSummary. The following figure shows a data transform that uses the data page to get the Account details and then set the value of pxobjclass. Figure 8: Data page definition The following figure shows the rule form for the D_CreditCardAccountSummary data page. Figure 9: FSIF Data Page 7-9

120 The following figure shows the properties in OpenMap DataTransform, which is missing the FSIF data transform. Figure 10: OpenMap data transform Integration Classes in Smart Dispute Each integration class maps to a corresponding database table. All the integration classes and rules are built in the PegaCardInt ruleset. All the integration classes use pattern inheritance to inherit from the PegaCard-Int class as shown below: 7-10

121 7-11

122 The following figure shows a high-level comparison of the old and new data retrieval process: The following procedure shows a high-level approach of retrieving data with the data pages implementation. 1. Create a Report Definition on the integration class. 2. Configure the Report Definition as the data source in the data page. 3. Use the Response data transform specified in the data page to map the Integration Layer properties to Data Layer properties. 4. Update the SQL- referenced activities with data transforms to invoke data pages. 7-12

123 Example Review the following D_CardGetTransactionDetail data page to understand the design. 7-13

124 The above MapResponseData data transform rule invokes the appropriate OpenMap data transform to map data between the INTEGRATION layer and the DATA layer. The OpenMap data transform rule is called polymorphically based on the page class definition. A wrapper rule to openmap, as shown above, is referenced during design time. At runtime, the specific data transform rule is executed. 7-14

125 Data Pages Used in Smart Dispute Access Designer Studio > Data Model > Clipboard Pages > Data Pages. 7-15

126 7-16

127 Generating Integration Classes Using the Metadata Accelerator Wizard The following figures illustrate the steps to generate the integration classes using metadata accelerator wizard 7-17

128 7-18

129 7-19

130 7-20

131 Note: Consider reusing the generic Response data transform ExtendMapResponseData during the implementation to map data between the Integration layer and the Data layer. 7-21

132 Usage of the ExtendMapResponseData rule The ExtendMapResponseData rule is used to invoke the data mapping action between the Integration layer and the Data layer. The rule uses the following parameters: OpenMapDTRuleInClass: Holds the Class name in which the Data transform rule is to be invoked DataTransformRuleName: Holds the name of the Data transform to be invoked AssociationClassName: Holds the pattern extension class name to read the properties from child classes, if required. 7-22