Smart Investigate For Issuer

Transcription

1 Smart Investigate For Issuer Implementation Guide V6.3.3

2 Smart Dispute for Issuers Implementation Guide Copyright 2012 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 described. 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. For Pegasystems trademarks and registered trademarks, all rights reserved. Other brand or product names are trademarks of their respective holders. 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. One Rogers Street Cambridge, MA Phone: (617) Fax: (617) Document: Software Version: Updated: December, 2013

3

4 Table of Contents Chapter 1:...Before You Begin... 2 Smart Dispute Overview... 2 Your Framework and Process Commander... 2 Who Should Read This Document?... 3 Education and Training... 4 Chapter 2:...Existing Functionality... 5 System Administrator Account... 5 RuleSet Hierarchy... 6 Work Object Naming Conventions... 7 Enterprise Class Structure Layer Cake Diagram... 7 Default Work Groups, Workbaskets, and Worklists... 8 Default Portals Predefined Access Roles and Privileges Predefined Organizations, Divisions, and Units Default Service Level Rules Correspondence Templates Smart Dispute Reports Chapter 3:...Understanding Smart Dispute Business Processing The Main Flow of Work in Smart Dispute Qualifying the Dispute using the TalkOff Flow Choosing a Reason Code using the ProcessDispute Flow Modifying the Provisional Credit Decision Tree Setting Up Automatic Write-Off Criteria Debit Transaction Dispute Processing Reg E Processing Multi-Dispute Claim Processing Chapter 4:...Extending Your Framework Structure Using DCO Tools What is Direct Capture of Objectives (DCO)? Using the DCO Tools Accessing DCO Tools Next Steps... 59

5 1 Chapter 5:...Personalizing Smart Dispute 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 Code Advisor Categories Defining New Bank Identification Numbers (BINs) Chapter 6:...Working With the Accounting Functions 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 Cutoff Times New Suspense Accounting Cut-off Times and the Calendar Adjusting Automatic Chargeback Understanding How Multi-currency Works Chapter 7:...Integrating Smart Dispute Creating Integration Activities Generating a Data Dictionary Smart Dispute for Issuers Implementation Guide

6 2 Smart Dispute for Issuers Implementation Guide Chapter 1: Before You Begin This document describes how to configure and integrate Smart Dispute for Issuers This document is intended for those who configure or integrate the Smart Dispute software, and assumes that the software is already installed. Smart Dispute Overview Smart Dispute is a comprehensive rules-based solution that automates the resolution of disputes and chargebacks for credit card, debit card, 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 to 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: Smart Dispute works best with Internet Explorer. The majority of downloaded ActiveX controls are for developers. Some ActiveX controls are dependent upon what a user is doing, such as editing during correspondence generation. If your organization does not allow this capability, ActiveX controls will not be downloaded. Your Framework and Process Commander Pega BPM contains a rules engine, database, processing logic, and functions providing the base upon which Pegasystems Frameworks are built. Pegasystems Frameworks are layered,

7 3 making use of underlying technology instead of reinventing process flows (Figure 1-1). Additional flows and rules are contained in the Framework layer and support applicationspecific 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. Figure 1-1. Process Commander Frameworks Showing Layers Because Pegasystems Frameworks all share the same underlying technology, configuration processes (such as creating accounts and copying rules) are identical to those in Pega BPM. You can use the Framework RuleSets as a starting point for extending the Framework, making it specific to your organizational needs. Who Should Read This Document? Before you install, deploy, and extend your Framework, it is assumed 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 Smart Dispute for Issuers Implementation Guide

8 4 Smart Dispute for Issuers Implementation Guide access, tuning, and troubleshooting. These users are presumed to be experienced with system operations. 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.

9 5 Chapter 2: Existing Functionality This chapter describes defaults and samples that are set up and ready for use. It is expected that you will use these as a basis for extending the Smart Dispute 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. Note: Operator IDs are not case sensitive, but passwords are case sensitive. This Operator ID gives you access to all the Claims Repair functions. Operator ID: DisputeSysAdmin Smart Dispute for Issuers Implementation Guide

10 6 Smart Dispute for Issuers Implementation Guide Password: install RuleSet Hierarchy RuleSets are arranged hierarchically, with the more general rules at the bottom and more specific rules at the top. The four RuleSets at the bottom are standard in all applications and control the underlying Process Commander operations, while the rules towards the top control application functions. The RuleSet order is critical to rule resolution. To find the appropriate rule, Process Commander begins with the top RuleSet in this list, and if the rule is not found moves to the next RuleSet. In this manner, custom, site-specific rules have precedence over application-specific rules. Figure 3-1 shows the RuleSet hierarchy with all the PegaCARD Smart Dispute Solution Framework layers. Figure 3-2. RuleSet Hierarchy The PegaCARD Smart Dispute Solution Framework RuleSets include: PegaCardSdConfig rules that are most commonly changed when deploying Smart Dispute. PegaCardSdIssuer rules that specifically pertain to the card issuer functionality in the Framework. PegaCardSdAdvisor rules that specifically pertain to the reason code advisor functionality in the Framework. PegaCardSd the general dispute rules that would be used for any dispute application. PegaCard the common card rules that would be used for any card application. PegaAppFin the common financial rules that would be used for any financial based application.

11 7 PegaApp the common application rules The Process Commander RuleSets include: Pega-ProCom workflow support and portal facilities Pega-IntSvcs system interface support, including connectors and services Pega-WB internal logic and facilities Pega-RULES activities, Java generation, rule resolution, and other basic rules engine operations Work Object Naming Conventions There are three primary types of work objects: basic work objects, covers, and folders. Applications use basic work objects; some, but not all, may use covers or folders. Work objects capture and process information about an individual unit of work. Covers tightly coordinate processing of one or more distinct, but closely related, work objects. The system normally resolves a cover work object after all its component work objects are resolved. Folders hold one or more work objects (which can be basic work objects, covers, or other folders). In contrast to covers, the relationship between folders and work objects and their contents may be many to many. One work object may be associated with multiple folders, but only one cover. 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. Each work object has a unique ID that is computed by combining a system-assigned number and a prefix defined in a pyworkidprefix model in the MyCoCardSd-Work-Disputeclass. The prefixes currently defined are: C- for claim work objects D- for dispute work objects Enterprise Class Structure Layer Cake Diagram Description or reference to best practice of using ECS Smart Dispute for Issuers Implementation Guide

12 8 Smart Dispute for Issuers Implementation Guide Sample Enterprise Class Structure Extending Smart Disputes Enterprise Reuse layer Division Reuse layer Implementation Layer Framework Layer Corp-App-Disputes Dispute Int- Work- Dispute Corp- FW- Data- Int- Corp-Div- Data- Int- Data- Int- Work- Corp-FW-DisputesFW- Data- Default Work Groups, Workbaskets, and Worklists Figure 3-2 lists the default work groups, workbaskets, and worklists found in the PegaCARD Smart Dispute Work Groups Disputes Merchant Workbasket RetrievalRequest CompleteInvestigation PendingReview PendingResearch ATM

13 9 PendingIssuerDocument MerchantResponseReview DisputeReviewRequired NACHA Fraud Exceptions Duplicates Visa SDWriteOff SDVerification SDSettlements SdRegZOperations CheckInCandidates AmericanExpress Arbitration AssociationSLA ChargeBackPending Compliance Disputes GoodFaith International MasterCard OnUs PendingDocument PendingResponse Representment SDAging SDCutOff SDImageResponse SdOperations Figure 3-3. Work Groups, Workbaskets Default Operators and Access Groups Smart Dispute ships with the operators and access groups listed in Figure 3-3. All passwords are set to install by default. Operator DisputeEntry Access Group DisputeEntry User Smart Dispute for Issuers Implementation Guide

14 10 Smart Dispute for Issuers Implementation Guide Operator DisputeFraudProcessing DisputeManager DisputeProcessing DisputeSimple DisputeSupervisor DisputeSysAdmin Access Group DisputeFraudProcessingUser DisputeManagerUser DisputeProcessingUser DisputeSimpleEntryUser DisputeSupervisorUser DisputeSysAdminUser Figure 3-4. Default Operator and Access Group Default Portals The tabs and tab names that users see on their home pages (or portals) when they log in are defined in access groups. Smart Dispute ships with the following layouts: CaseManager DisputeSysAdmin CaseManager Portal Figure 3-5. CaseManager Portal

15 11 DisputeSysAdmin Figure 3-6. Dispute Sys Admin Portal Predefined Access Roles and Privileges Your Framework includes a set of predefined access roles and privileges (Figure 3-6). Smart Dispute for Issuers Implementation Guide Dispute Entry Fraud Manager Dispute Processin g Clerical Superviso r Privileges Adjustment X X X ChangeCaseType 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 FinOffsetSearch ForceWriteOff X X X GetNewWorkFromConf X X X X X X X InitiateCollection X X X X X Link LowerPayable LowerReceivable NonFinOffsetSearch SysAdmin

16 12 Smart Dispute for Issuers Implementation Guide Dispute Entry Fraud Manager Dispute Processin g Clerical Superviso r Privileges Offset OpenCaseFromConf X X X X X X X OpenPayable X X X X X X X OpenReceivable X X X X X X X PerformFromReview X X X X X X X RaisePayable RaiseReceivable Reopen 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 X X VerifyLevel2 X X VerifyLevel3 X WriteOffAdjustment X X X WriteOffAged X X X WriteOffPayable X X X WriteOffReceivable X X X Figure 3-7. Smart Dispute Roles and Associated Privileges SysAdmin Predefined Organizations, Divisions, and Units Smart Dispute comes with the following predefined organization, division, and units. Organization: Division: Units: Pega.com 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 Rule-Declare- Expression. 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,

17 13 Goal, Deadline, and Late fields of the Service Level rule form (as described in the previous topic). Figure 3-7 lists the default service level rules that come with Smart Dispute, along with the default goals, deadlines, and activities. (PegaCARD-Sd-Dispute-!) Description Goal Goal Activity Deadline Deadline Activity ACTIONFULFILLMENT ACTIONMEDIATIONRULING Action Fulfillment Assignment Action Mediation Ruling Assignment ACTIONMEDIATIONRULING 3 7 ACTIONMEDIATIONRULINGNF 8 10 ACTIONNONFULFILLMENT ANSWERQUESTIONS Action Non Fulfillment Assignment Answer Questions for Assignment ARBCBINITIATION ARBITRATION Arbitration Assignment 1 1 ARBITRATIONWB Arbitration Workbasket Assignment ARBITRATIONWBINTL Arbitration Workbasket for International Assignment ASSIGNFORAGEDWRITEOFF Assign For Aged WriteOff Assignment (called via MapValue!) FinResumeAgedWrite Off2 ASSOCIATIONSLA AssociationSLA 0 OverrideOverallSLA 0 ActionTransferToWork Basket CHARGEBACKREVERSALASSIGN CHECKFORRESPONSE30 Chargeback Reversal Assign Assignment Check 30 days for response - Pending Fulfillment AdvanceFlow COMPLIANCE Compliance Assignment 1 1 Smart Dispute for Issuers Implementation Guide

18 14 Smart Dispute for Issuers Implementation Guide (PegaCARD-Sd-Dispute-!) Description Goal Goal Activity Deadline Deadline Activity COMPLIANCEWB Compliance COMPLIANCEWBINT DECISIONINBOUNDARBITRATION SLA for Decision Inbound Arbitration Assignments DISPUTEMAINFLOW SLA passed into OverAll SLA Flow to run on Disputes 30 UrgencyUpdateAssign ments 60 UrgencyUpdateAssign ments FINAGEDWRITEOFF FINSTEPCUTOFF 5 hours 10 hours FINWRITEOFFAFTER30 Wait 30 days before Aged Write Off 30 FinResumeAgedWrite Off2 30 FinResumeAgedWrite Off2 FINWRITEOFFAFTER FINWRITEOFFAFTER FINWRITEOFFAFTER GOODFAITHOUTBOUND Good faith wait for 30 days 30 ResumeGoodfaith 30 ResumeGoodfaith GOODFAITHWB GOODFAITHWBOUTBOUND Good Faith Workbasket Assignment Good Faith Workbasket (Outbound) Assignment ResumeGoodfaith HASDUPLICATES Has Duplicate Assignment 1 1 INBOUNDARBITRATION INBOUNDCOMPLIANCE INBOUNDPREARBITRATION INITIATEPREARBITRATION INVOKEINSERTDISPUTEDETAILS Inbound Arbitration Assignment Inbound Compliance Assignment Inbound PreArbitration Assignment Initiate PreArbitration Assignment Invoke Insert Dispute Details Assignment MEDIATION7 Service level Mediation7 7 7

19 15 (PegaCARD-Sd-Dispute-!) Description Goal Goal Activity Deadline Deadline Activity NONFULFILLMENTASSIGNMENT Non Fulfillment Assignment Assignment 1 3 OPERATOR SLA for Operator Assignment 1 1 PAYABLEWRITEOFFSLA Wait 180 days before Aged Write Off (Payable) ResumeAgedWriteOff 2 PENDCHARGEBACK Pending Chargeback 0 ResumeIfCredited 0 ResumeCreditedOrNo t PENDFORFULLFILLMENT PENDINGCARDHOLDERRESPONS E PENDINGFEECOLLECTION Pending For Fulfillment Assignment Pending Fee Collection SLA AdvanceFlow 2 minutes 5 minutes PENDINGFUNDSDISBURSEMENT PREARBITRATION Prearbitration wait for 30 days 0 ResumePreArbitration 0 ResumePreArbitration PREARBITRATIONOUTBOUND PREARBITRATIONWB SLA for Prearbitration Workbasket Assignment PRECOMPLIANCEOUTBOUND Good faith wait for 30 days 30 ResumePreComplianc e 30 ResumePreComplianc e PRECOMPLIANCEWB Precompliance Workbasket Assignment PRECOMPLIANCEWBOUTBOUND Precompliance Workbasket (Outbound) Assignment ResumePreComplianc e PROCESSCHARGEBACK Process Chargeback Assignment 1 2 PROCESSDISPUTE Process Dispute Assignment 5 10 PROCESSDUPLICATEREQUESTS Process Duplicate Requests Assignment 1 1 Smart Dispute for Issuers Implementation Guide

20 16 Smart Dispute for Issuers Implementation Guide (PegaCARD-Sd-Dispute-!) Description Goal Goal Activity Deadline Deadline Activity PROCESSONUSDISPUTES Process OnUs Disputes Assignment 2 5 PROCESSSECONDCHARGEBACK QUALIFYDISPUTE QualifyDispute Assignment 0 0 QUESTIONTOCONTINUEDISPUTE Question To Continue Dispute Assignment 0 0 QUESTIONTOCONTINUETALKOFF Question To Continue TalkOff Assignment 0 0 ResumeAgedWriteOff 2 RECEIVABLEWRITEOFFSLA Wait 180 days before Aged Write Off (Receivable) REGZCREDIT Regulation Z SLA 1 2 ResumePreArbitration REPRESENTMENT REPRESENTMENTASSIGNMENT Prearbitration wait for 30 days Representment Assignment 0 ResumePreArbitration ResumeFlow REPRESENTMENTDOCASSIGNME NT Wait For Docs Assignment in Representment Flow RESOLVECHARGEBACK Resolve Chargeback Assignment SENDEDITACKNOWLEDGELETTER Send Edit Acknowledge Letter Assignment 1 2 SENDEDITCARDHOLDERLETTER SENDEDITCOVERLETTER SENDEDITGOODFAITHLETTER Send Edit Cardholder Letter Assignment Send Edit Cover Letter Assignment Send Edit Good Faith Letter Assignment SENDEDITMCCOVERLETTER 1 2 SENDEDITPREARBITRATIONLETT ER Send Edit PreArbitration Letter Assignment 1 2 SENDEDITPRECOMPLIANCE Send Edit Precompliance Assignment 1 2 UrgencyUpdateAssign ments

21 17 (PegaCARD-Sd-Dispute-!) Description Goal Goal Activity Deadline Deadline Activity STANDARD TALKOFFPROCESS Talk Off Process Assignment 0 0 UNTIMELY Untimely Assignment 1 2 WAITFORDOCUMENT Wait For Document Assignment WRITEOFFAFTER minutes 5 minutes ConfirmReversePCFromClaim Complete Investigation service level 1 sec ProcessReverseClaim LevelPCAcctg ReverseProvisionalCreditFromClai m Complete Investigation service level 1 sec ReverseProvisionalCr editfromclaim WaitForRegEFinal90 Wait for RegE Final 90 service level WaitForRegEFinal45 Wait for RegE Final 45 service level WaitForRegEPCDate WaitForSignedAffidavit Wait for RegEPCDate service level SL for Customer to return Signed Affidavit 8 days 10 days WaitForDocument Wait For Document 8days ReminderToReturnDo cument 10 days WaitForNACHA Wait For NACHA. WaitForDocument Wait For Document 8days ReminderToReturnDo cument 10 days CompleteInvestigation Complete Investigation service level. ReminderToReturnWS UD ReverseProvisionalCredit Complete Investigation service level 4minutes ReverseProvisionalCr edit ProcessFinalCredit EscalateCompleteInvestigation Process Provisional Credit final service level Escalate Complete Investigation. ProcessFinalCredit. EscalateToSupervisor Figure 3-8. Default Service Level Rules Smart Dispute for Issuers Implementation Guide

22 18 Smart Dispute for Issuers Implementation Guide 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 association time-frames 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/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/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 Different urgency values can be assigned based on the originator of the work object. Additional urgency points can be added based on the dollar value of the work object. The user interface lists work objects with higher urgency totals at the top of 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

23 19 Cardholder liable 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. Figure 3-8 lists the Smart Dispute templates that are part of the Framework. Process Commander also comes with a standard set of correspondence templates for Work- (not shown here). Class Name Stream Name Corr Type PegaCard-Sd-Claim CustomerLiableCorrTemplate Mail PegaCard-Sd-Claim ProvisionalCreditCorrNotification Mail PegaCard-Sd-Claim ConfirmReversePCCorrFromClaim Mail PegaCard-Sd-Claim CloseClaimCorrespondenceTemplate Mail PegaCard-Sd-Claim FraudAffidavitCorrespondence Mail PegaCard-Sd-Claim test Mail PegaCard-Sd-Claim ProvisionalCreditFinalNotice Mail PegaCard-Sd-Claim NotifyReverseProvisionalCredit Mail PegaCard-Sd-Claim- ResearchingClaim Mail PegaCard-Sd-Claim- ResolvedClaim Mail PegaCard-Sd-Claim- Header Mail PegaCard-Sd-Claim- Footer Mail PegaCard-Sd-Claim- CardHolderAffidavitClaim Mail PegaCard-Sd-Claim- AcknowledgeClaim Mail PegaCard-Sd-Debit ReverseProvisionalCreditNotification Mail PegaCard-Sd-Debit FinalCreditWithFee Mail PegaCard-Sd-Debit ProvisionalCreditNotification Mail PegaCard-Sd-Debit PCFinal Mail PegaCard-Sd-Debit PCWithFeeFinal Mail PegaCard-Sd-Debit ReverseProvisionalCreditAndFeeNotification Mail Smart Dispute for Issuers Implementation Guide

24 20 Smart Dispute for Issuers Implementation Guide Class Name Stream Name Corr Type PegaCard-Sd-Debit ReminderToReturnWSUD Mail PegaCard-Sd-Debit EscalateToSupervisor PegaCard-Sd-Debit RequestPOA Mail PegaCard-Sd-Debit NoticeToReversePC Mail PegaCard-Sd-Debit FinalCredit Mail PegaCard-Sd-Debit SorryLetter Mail PegaCard-Sd-Debit ProvisionalCreditWithFeeNotification Mail PegaCard-Sd-Debit ReminderToReturnDocument Mail PegaCard-Sd-Debit-ACH ProvisionalCreditWithFeeNotification Mail PegaCard-Sd-Debit-ACH CreditNoticeFeesOnly Mail PegaCard-Sd-Debit-ACH ProvisionalCreditNotification Mail PegaCard-Sd-Debit-ACH SorryLetter Mail PegaCard-Sd-Dispute Footer Mail PegaCard-Sd-Dispute- VisaHeader Mail PegaCard-Sd-Dispute- CardHolderLiable Mail PegaCard-Sd-Dispute- ResolvedCardholderFavor Mail PegaCard-Sd-Dispute- AcknowledgeSample PegaCard-Sd-Dispute- CardHolderAffidavit Mail PegaCard-Sd-Dispute- Footer PegaCard-Sd-Dispute- GeneralCoverLetter Mail PegaCard-Sd-Dispute- GeneralHeader Mail PegaCard-Sd-Dispute- GoodFaithLetter Mail PegaCard-Sd-Dispute- Header PegaCard-Sd-Dispute- PreArbitration Mail PegaCard-Sd-Dispute- PreComplianceLetter Mail PegaCard-Sd-Dispute- CardHolderLiable_Pauld Mail PegaCard-Sd-Dispute- AcknowledgeLetter Mail PegaCard-Sd-Dispute- AcknowledgeSample Mail PegaCard-Sd-Dispute- CardHolderLetter Mail PegaCard-Sd-Dispute- CHLetter62_3 Mail PegaCard-Sd-Dispute- ClosedNoReply Mail PegaCard-Sd-Dispute- Footer Mail PegaCard-Sd-Dispute- FullfillmentLetter Mail PegaCard-Sd-Dispute- Header Mail PegaCard-Sd-Dispute- Reminder Mail PegaCard-Sd-Dispute- RequestForInformation Mail PegaCard-Sd-Dispute- RequestToContactMerchant Mail PegaCard-Sd-Dispute- ResolvedCardholderFavour Mail

25 21 Class Name Stream Name Corr Type PegaCard-Sd-Dispute- VisaCoverLetter Mail PegaCard-Sd-Dispute-MC- CardHolderLiable Mail PegaCard-Sd-Dispute-MC- EBDBillingDiscrepancies Mail PegaCard-Sd-Dispute-MC- EBDCanceledServicesReturnedMerchandise Mail PegaCard-Sd-Dispute-MC- EBDDefectiveNotAsDescribed Mail PegaCard-Sd-Dispute-MC- EBDNonReceiptOfMerchandise Mail PegaCard-Sd-Dispute-MC- EBDNotElsewhereClassified Mail PegaCard-Sd-Dispute-MC- EBDResolutionProcessForm Mail PegaCard-Sd-Dispute-MC- EBDServicesNotRendered Mail PegaCard-Sd-Dispute-MC- EXPBillingForm Mail PegaCard-Sd-Dispute-MC- GoodFaithLetter Mail PegaCard-Sd-Dispute-MC- Header Mail PegaCard-Sd-Dispute-MC- IssuerCertificationTemplate Mail PegaCard-Sd-Dispute-MC- MCCoverLetter Mail PegaCard-Sd-Dispute-MC- MCHeader Mail PegaCard-Sd-Dispute-MC- PaymentByOtherMeans Mail PegaCard-Sd-Dispute-MC- PreArbitration Mail PegaCard-Sd-Dispute-MC- RegulationsRulesViolation Mail PegaCard-Sd-Dispute-MC- RegulationsRulesViolationPreCom Mail PegaCard-Sd-Dispute-MC- RequestToContactMerchant Mail PegaCard-Sd-Dispute-MC- ResolvedCardholderFavor Mail PegaCard-Sd-Dispute-MC- SummaryOfArbitrationDocumentation Mail PegaCard-Sd-Dispute-MC- MEBNoShowDisputeForm Mail PegaCard-Sd-Dispute-MC- AddendumDispute Mail PegaCard-Sd-Dispute-MC- POICrncyConversionDisputeEBF Mail PegaCard-Sd-Dispute-MC- EXPBillingFormFor4831 Mail PegaCard-Sd-Dispute-MC- InstallmentBillingDispute Mail PegaCard-Sd-Dispute-Visa-International- ResolvedCardholderFavor Mail PegaCard-Sd-Dispute-Visa-International- TransactionInformation Mail PegaCard-Sd-Dispute-Visa-International- AdditionalInformation Mail PegaCard-Sd-Dispute-Visa-International- CardholderInformation Mail PegaCard-Sd-Dispute-Visa-International- Exhibit2E2 Mail PegaCard-Sd-Dispute-Visa-International- Exhibit2E_1 Mail PegaCard-Sd-Dispute-Visa-International- Exhibit2E_2 Mail PegaCard-Sd-Dispute-Visa-International- Exhibit2E_3 Mail PegaCard-Sd-Dispute-Visa-International- Exhibit2E_4 Mail PegaCard-Sd-Dispute-Visa-International- Exhibit2E_5 Mail PegaCard-Sd-Dispute-Visa-International- Exhibit2E_6 Mail Smart Dispute for Issuers Implementation Guide

26 22 Smart Dispute for Issuers Implementation Guide Class Name Stream Name Corr Type PegaCard-Sd-Dispute-Visa-International- Header Mail PegaCard-Sd-Dispute-Visa-International- IssuerCertificationTemplate Mail PegaCard-Sd-Dispute-Visa-International- IssuerCertificationTemplt Mail PegaCard-Sd-Dispute-Visa-International- MemberContactInformation Mail PegaCard-Sd-Dispute-Visa-International- MemberInformation Mail PegaCard-Sd-Dispute-Visa-International- RequestForInformation Mail PegaCard-Sd-Dispute-Visa-International- VisaHeader Mail PegaCard-Sd-Dispute-Visa-International- Exhibit2E_2 Mail Canada- PegaCard-Sd-Dispute-Visa-Us- Exhibit1A Mail PegaCard-Sd-Dispute-Visa-Us- Exhibit1ATest Mail PegaCard-Sd-Dispute-Visa-Us- RequiredSupportingInfo Mail PegaCard-Sd-Dispute-Visa-Us- Test Mail PegaCard-Sd-Dispute-Visa-Us- TransactionDetail Mail PegaCard-Sd-Dispute-Visa-Us- VisaUSExibit2A Mail PegaCard-Sd-Dispute-Visa-Us- VisaUSExibit3A Mail PegaCard-Sd-Dispute-Visa-Us- VisaUSExibit4A Mail PegaCard-Sd-Dispute-Visa-Us- VisaUSExibit5A Mail PegaCard-Sd-Dispute-Visa-Us- VisaUSExibit6A Mail PegaCard-Sd-Dispute-Visa-Us- VisaUSExibit7A Mail PegaCard-Sd-Dispute-Visa-Us- VisaUSExibitMisc Mail PegaCard-Sd-Dispute-Visa-Us- AdditionalComments Mail Figure 3-9. PegaCARD Smart Dispute Correspondence Templates 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.

27 23 s are generated through capabilities built into PegaRULES Process Commander. The routing, printing, and faxing of correspondence is 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 will be generated, attached to the claim or dispute, and can be reviewed online in its printed form. It won t 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. This section contains the full list of available reports, organized in the following categories: Accounting Reports End of Day Balancing Suspense Write-off Quality Reports Resolution Quality History Monitor Activity Reports Monitor Process Assignments Monitor Processes Analyze Process Quality Analyze Process Performance Reg E Reports If a graph is available for the report, a check mark appears in the Graph column. Smart Dispute for Issuers Implementation Guide

28 24 Smart Dispute for Issuers Implementation Guide Accounting Reports End of Day Balancing Report Name All account types today All account types specified dates Payable and receivable only today Payable and receivable only specified dates Graph Suspense Reports Report Name Outstanding summary Outstanding age Outstanding amount range Resolved today Resolved past 7 days Resolved past 30 days Resolved specified dates Graph Write-Off Reports Report Name Today Specified Dates Graph Quality Reports Resolution Quality Reports Report Name By work owner specified date range By work owner 30 days By work owner 90 days By work resolver specified date range By work resolver 30 days By work resolver 90 days Graph History Analysis Reports Report Name Work history count Monitor Process Assignment Reports

29 25 Summary Reports Report Name Timeliness by assigned organization Timeliness by operator Timeliness by operator and work type Timeliness by work queue Timeliness by task Timeliness by work type Timeliness by work group, operator Timeliness of top process owners Timeliness by operator and work type Graph List Reports Report Name Assignments for workbasket Work by operator Work for work basket Graph Monitor Processes Reports Summary Reports Report Name Timeliness by work type Timeliness by organization unit Process status Throughput in past week by work type Progress by organization Progress by organization unit Effort progress, grouped by customer Open count of work, grouped by status Timeliness by organization unit Timeliness by work type Graph List Reports Report Name Entered by me Work by resolved operator Graph Smart Dispute for Issuers Implementation Guide

30 26 Smart Dispute for Issuers Implementation Guide Analyze Process Quality Reports Summary Reports Report Name Timeliness by resolving unit Timeliness by work type Average elapsed time per status Effort by customer Daily process resolution by work group Weekly process creation by work type Elapsed time in different states, by originator Quality by customer Timeliness by originator Timeliness by resolving unit Top process resolvers Graph Analyze Process Performance Reports Summary Reports Report Name Task duration Timeliness by task Task performance Action analysis Action processing time Performance detail Action performance Action processing time in hours Graph Regulation E Reports Summary 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 Graph

31 27 Report Name Reg E Audit Report, Open Items Reg E Audit Report, Resolved Items Graph Smart Dispute for Issuers Implementation Guide

32 28 Smart Dispute for Issuers Implementation Guide Chapter 3: Understanding Smart Dispute Business Processing Processing in Smart Dispute is controlled by flows. These flows determine which screens you see and what 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 begin entering 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 on page 32. 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 DisputeMainFlow flow diagram on page 45. 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 dispute. Dispute Stages In the extreme scenario where a Dispute continues throughout the entire adjudication process, the follow Dispute Stages will occur:

33 29 Ticket Retrieval (optional) Chargeback Representment PreArbitration Arbitration 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 diagram on page 32. Figure 4-1 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, etc., 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, etc., depending on the details of the dispute. Good Faith GoodFaithInbound Creates an assignment to record a response received from an acquirer, indicate whether the acquirer granted or declined the request, and how any remaining balance is to be treated. Figure Processing Based on the DisputeStage Property If the Dispute Stage is other than one of the values listed in Figure 4-1, 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 on page 32. If your organization processes On-Us and non On-Us disputes the same, you may wish to remove the On-Us Flow from the Dispute Main Flow. Smart Dispute for Issuers Implementation Guide

34 30 Smart Dispute for Issuers Implementation Guide 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 on page For step-by-step information about the TalkOff flow, see Qualifying the Dispute using the TalkOff Flow on page 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 on page 325. 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 only used 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 on page 45. For debit transactions, Smart Dispute determines if the transaction/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 what dates certainly processing steps need to be completed. See Debit transaction dispute processing. 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 on page 45. 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 on page 32. For step-by-step information about the ProcessDispute flow, see Choosing a Reason Code using the ProcessDispute Flow on page 45. DisputeMainFlow also includes other utilities and tickets that manage internal details for the Smart Dispute program.

35 31 DisputeMainFlow Flow Diagram The DisputeMainFlow diagram shows the backbone of Smart Dispute processing for credit card disputes. Smart Dispute for Issuers Implementation Guide

36 32 Smart Dispute for Issuers Implementation Guide Figure Flow Diagram for PegaCard-Sd-Dispute-DisputeMainFlow 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 actions that it might display are: Qualify Dispute Action Resolve Dispute with Merchant Action 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. The TalkOff flow is shown on page 48. 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 on page 48. 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.

37 33 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 that process a lost or stolen card. This step is part of the IdentifyTransaction Invoke Flow shape shown in the TalkOff flow diagram on page 48. Smart Dispute continues processing the dispute, based on the answers that you provide to these questions. These are two examples, however, the questions that Smart Dispute presents, as well as the processing that occurs in the background, can be customized. The flows, and logic that drives them, can be easily modified to fit the specific needs of your organization. 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 on page 48. 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 on page 48. 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 on page 48. Smart Dispute for Issuers Implementation Guide

38 34 Smart Dispute for Issuers Implementation Guide 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. Figure Flow Diagram for PegaCard-Sd-Dispute-TalkOff

39 35 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 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. The ProcessDispute flow is shown on page 50. 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 to determine 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 to determine 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. Smart Dispute for Issuers Implementation Guide

40 36 Smart Dispute for Issuers Implementation Guide 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. 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. Figure Flow diagram for PegaCard-Sd-Dispute-ProcessDispute

41 37 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 Class Explorer tab. 2. Choose Rule- from the drop down select box. 3. Select Declare- > DecisionTree. A list of rules appears. 4. Click IsProvisionalCredit. A Decision Tree form appears (Figure 6-14). Figure Modifying the IsProvisionalCredit Decision Tree 5. Click Save As. The Save As form appears. 6. Select ClassName-Sd-Dispute- from the Class Name list (where ClassName is your toplevel class name), select your RuleSet from the selection box, and then click Save As. 7. Edit the If statements as needed. Smart Dispute for Issuers Implementation Guide

42 38 Smart Dispute for Issuers Implementation Guide 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. 8. 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 decision tree (IsWriteOff) is then 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 Class Explorer tab. 2. Choose Rule- from the drop down select box. 3. Select Declare- > DecisionTree. A list of rules appears.

43 39 4. Click IsWriteOff. A Decision Tree form appears (Figure 6-15). Figure Modifying the Write-Off Decision Tree 5. Click Save As. The Save As form appears. 6. Select ClassName-Sd-Dispute- from the Class Name list (where ClassName is your toplevel class name), select your RuleSet from the selection box, and then click Save As. 7. Edit the If statements as necessary. Smart Dispute for Issuers Implementation Guide

44 40 Smart Dispute for Issuers Implementation Guide 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. 8. 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 Class Explorer tab. 2. Choose Rule- from the drop down select box. 3. Selet Obj- > MapValue. A list of rules appears. 4. Click WriteOffOnLower. A Decision Tree form appears (Figure 6-16). Figure Modifying a Write-Off Threshold 5. Click Save As. The Save As form appears. 6. Select ClassName-Sd-Dispute- from the Class Name list (where ClassName is your toplevel class name), select your RuleSet from the selection box, and then click Save As. 7. Enter a new write-off threshold. 8. Click Save.

45 41 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 provides you with the ability to 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 Class Explorer tab. 2. Choose Rule- from the drop down select box. 3. Select Obj- > ServiceLevel. A list of rules appears. 4. Click ReceivableWriteOffSLA. A Service Level form appears (Figure 6-17). Figure Write-Off Service Levels 5. Click Save As. 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. Smart Dispute for Issuers Implementation Guide

46 42 Smart Dispute for Issuers Implementation Guide 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 (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 Class Explorer tab. 2. Choose Rule- from the drop down select box. 3. Select Obj- > MapValue. A list of rules appears. 4. Click PayableWriteOffSLA or ReceivableWriteOffSLA. A Map Value form appears (Figure 6-18). Figure Modifying a Write-Off SLA Rule 5. Click Save As. 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. You can specify an age threshold or you can set the age threshold based on the outstanding balance. 7. Click Save.

47 43 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 Distinct write-off criteria can be set for debit/deposit account disputes in the decision table IsWriteOff: 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. The user can decide if any or all of these various fees need to be credited back to the customer. Use SelectChargeFees flow as an integration point to present the appropriate fees to the user. ACH Commercial Disputes SEC Codes Commercial SEC codes in ACH transactions are typically handled with different SLA and by a different set of operators. A When condition evaluates the SEC codes the transaction is processed as a commercial dispute if the SEC code associated with the transaction is CCD or CTX. By default, the ACH return reason R05 is set as return code for transactions with SEC code CCD, and R31 for CTX code. For either of these SEC codes, the customer is given immediate credit and the dispute is Resolved-WrittenOff. Smart Dispute for Issuers Implementation Guide

48 44 Smart Dispute for Issuers Implementation Guide The flow CommercialDisputeFlow can be updated for further extension and reusability. 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. These rules can be extended for other error descriptions, as well as for other ATM networks in which the bank participates.

49 45 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. 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 When rule, IsUSDepAccount 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 When rule IsRegECreditRequired compares the SetNoRegECredit date to the transaction date to determine if the dispute is subject to Reg E. Smart Dispute for Issuers Implementation Guide

50 46 Smart Dispute for Issuers Implementation Guide Verbally Attest The Flow action VerballyAttest allows the user 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-of-sale) Transaction Currency is the same as Posting currency Set the RegEPC date to +20 business days if: The Account Open date is less than 30 days ago Set 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 these two statements are true: CHIdMethod is 2 or Transaction Currency is not the same as Posting currency

51 47 Provide Provisional Credit The When rule IsEligibleForREGEPC 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 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 deposit account current balance is > 0 Smart Dispute for Issuers Implementation Guide

52 48 Smart Dispute for Issuers Implementation Guide Reverse Provisional Credit Reg E specifies that if you reverse provisional credit, because you find the customer liable for example, you must notify him 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 5 th 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 transactions that he did not authorize because his 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 gadget, the user can select more than one transaction from the transaction list on the Transaction Search screen to create and add multiple Disputes to the Claim during case creation. The claim, which will include all selected disputes, will be 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 the user to qualify the customer s claim of fraud. Extend that flow action in the field for additional questions. Other Bulk Actions

53 49 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, the user is brought to the Claim review harness where they can see the individual Disputes listed for the Claim and can select any number of Disputes from the list for available Bulk Action. Additionally, more Disputes can be added to the Claim at this stage from the Add Multiple Disputes button if needed. Validation is provided for Bulk Action that ensures assignments are processed in order that follow the straight through dispute workflow for single dispute. For example, if a user tries 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 allows the user 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, disputes 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 the user can filter the list of disputes accordingly. 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, we ve configured the debit payment channel to include the Visa Signature, MC Signature, Visa Pin (Interlink) and MC Pin (Maestro.) Another customer may decide 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 the user 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 for Smart Dispute for Issuers Implementation Guide

54 50 Smart Dispute for Issuers Implementation Guide the user to 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. Other accounting entries, like write-off and chargeback, can be selected as bulk actions from the claim level. The entries will be 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 will not be 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. 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 is Qualify Fraud Aff Prov Credit Reason Code Chg Back Cust Liable Write Off

55 51 Reverse PC PC Final This list can be extended or updated in the field. Close Claim The claim-level action Close Claim can be selected once all disputes are in resolved statuses. The action allows the user to select the claim status from a drop down list. Smart Dispute for Issuers Implementation Guide

56 52 Smart Dispute for Issuers Implementation Guide Chapter 4: Extending Your Framework Structure Using DCO Tools This chapter describes how to plan for and extend your framework structure using PRPC Direct Capture of Objective (DCO) tools. Before you extend and customize the framework, you should: 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 an application profile that fills in the gaps Create the extended structure and base rules from the application profile Topics are: What is Direct Capture of Objects (DCO) Using the DCO Tools What is Direct Capture of Objectives (DCO)? DCO is a suite of features that enable project team members to directly capture, organize and manage business specifications inside of PRPC and associate them with the specific parts of the application that are implementing them. Designed as an enabling technology suite, it can be used 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 in and of itself. It is an agile process that is adaptable to any size project and can be used in conjunction 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 life-cycle. The Direct Capture 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.

57 53 Application Profiler captures objectives, specifications, requirements, processes, interfaces, reports, correspondence, and case type relationships; estimates project sizings; documents the collected information as an application profile document; jump starts application development by providing the information as input to the Application Accelerator. Application Accelerator jump starts the creation and extension of your application and automates best practices for application design; consuming information from an application profile, it creates organization and class structures, case type relationships, and draft processes and user interface elements so you can see the working application based on the captured information. Using the DCO Tools This section contains the steps to extend your framework using the Direct Capture of Objects tool. Document your Framework s Current Assets Create Your Application Profile Generate Your Sizing Run the Application Accelerator Accessing DCO Tools To access and use the DCO tools, log onto the framework as an administrator that is able to access the Designer Studio. If you have not created a custom administrator, log on as User: Password: DisputeSysAdmin install Step 1: Document Your Framework s Current Assets This step uses 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. Smart Dispute for Issuers Implementation Guide

58 54 Smart Dispute for Issuers Implementation Guide 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. 1. Select >Application > Tools > Document. 2. On the Select tab, choose the following options. a. In the Application section, select: Application = SmartDispute_ALL (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. Note: Some of the assets that are displayed in the Profiler have been deprecated in subsequent releases. These deprecated assets should have the word Deprecated in either the Title and/or Description. There are some updates needed to clean up the list of assets that will take some time to resolve. In the meantime work with your Lead System Architect (LSA) and Product Owners (PO) to make sure the appropriate assets are being leveraged. For additional information about the options and fields on this or any other tab displayed by the Document tool, click to display help text in a separate window. 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.

59 55 Step 2: Create Your Application Profile In this step, you create the application profile that you use to define the class structure and rule extensions of the framework you want to build upon. Profiles are intended to be developed over a period of time and can be opened and updated as needed before you build the application using the Application Accelerator as described in Step Click the Application Name displayed in the upper left hand corner of the portal and select New Application > Application Profile from the menu. 2. On the Application Overview popup window, enter or select the following values. Profile Options = New Application Build = New Framework and Implementation Build on Framework = SmartDispute_ALL ( Choose this if you are using all the Associations, if not you can use any specific Association Applications like SmartDispute_AMEX) Version = Application name = enter what s appropriate for the organization Project Name = enter what s appropriate for the organization Project Led By = enter what s appropriate for the organization Organization Name = enter what s appropriate for the organization Business Objectives = defaulted from the Framework you select, however you can modify, delete, or add any that are appropriate for the organization Project Descriptions = enter what s appropriate for the organization Smart Dispute for Issuers Implementation Guide

60 56 Smart Dispute for Issuers Implementation Guide Click OK to display and complete the Profiler input tabs. The information that defaults into the tabs comes from your current application/framework structure. For additional information and instructions about the options and fields on the tabs and the profiler actions, click to display help text in a separate window. 3. Click to complete the profile.

61 57 Step 4: Run the Application Accelerator Once you complete your Application Profile by clicking on the Project Explorer tab, you can run the Application Accelerator from the profile s resolution display by clicking. Alternatively, you can open the Accelerator clicking the Application Name displayed in the upper left hand corner of the portal and selecting New Application > Application Accelerator from the menu. Then, select the Application Profile you want to use to generate the application. 4. When the Application Overview popup window displays, it defaults information from the profile. Click OK to display all of the Accelerator tabs. 5. On the Rule and RuleSets tab, make sure the Class Structure value that is selected is Extended. Smart Dispute for Issuers Implementation Guide

62 58 Smart Dispute for Issuers Implementation Guide For additional information and instructions about the options and fields on this or any other tab displayed by Application Accelerator, click to display help text in a separate window. Configuration Warning: On the Base and RuleSets and Class Structure tabs, when class names you enter exceed 56 characters in length, a symbol appears. The best and recommended practice is to reduce values you enter to 3 characters to make sure the limit is not exceed. You can also open and modify one of the ancestor classes to correct this condition.

63 59 6. Continue to complete the tabs in the Accelerator as needed remembering to adjust the length of class names when the icon appears. 7. Click to create your new application. Next Steps Now that you have built the base application on which to develop, you can begin enhancing and expanding the base rules and other components of the application created by the accelerator. This allows you to facilitate your ongoing Direct Capture Objectives sessions with a demonstrable application that you can continue to build out and evolve. Step 1: Updating the Built On Application If your newly created Application is built on Application rule SamrtDispute_ALL, 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: 1. Base functionality or Association specific 2. Where applicable for Visa, a Region can also be specified, as follows: Smart Dispute for Issuers Implementation Guide

64 60 Smart Dispute for Issuers Implementation Guide 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, here are three possible ruleset scenarios (ignore the spaces when adding the rulesets): All Associations, All Regions Visa All Regions Visa US and Canada MyCoCardSdVisaAP:04-02 MyCoCardSdVisaCEMEA:04-02 MyCoCardSdVisaInterlink:04-02 MyCoCardSdVisaCEMEA:04-02 MyCoCardSdVisaInterlink:04-02 MyCoCardSdVisa:04-02 MyCoCardSdVisaInterlink:04-02 MyCoCardSdVisaLAC:04-02 MyCoCardSdAdvisor:04-02 MyCoCardSdVisaLAC:04-02 MyCoCardSdVisaEurope:04-02 MyCoCardSd:04-04 Sample App MyCoCardSdVisaEurope:04-02 MyCoCardSdVisa:04-02 MyCoCardSdMasterCard:04-01 MyCoCardSdVisa:04-02 MyCoCardSdAdvisor:04-02 MyCoCardSd:04-04 MyCoCardSdAMEX:04-01 MyCoCardSdAdvisor:04-02 MyCoCardSd:04-04 PegaCardSdAdvisorVisaAP:04-02 PegaCardSdAdvisorVisaAP:04-02 PegaCardSdAdvisorVisaInterlink:04-02 PegaCardSdAdvisorVisaCEMEA:04-02 PegaCardSdAdvisorVisaCEMEA:04-02 PegaCardSdAdvisorVisaCanada:04-03 SD Framework PegaCardSdAdvisorVisaInterlink:04-02 PegaCardSdAdvisorVisaInterlink:04-02 PegaCardSdAdvisorVisaUS:04-02 PegaCardSdAdvisorVisaLAC:04-02 PegaCardSdAdvisorVisaLAC:04-02 PegaCardSdVisaUS: PegaCardSdAdvisorVisaEurope:04-02 PegaCardSdAdvisorVisaEurope:04-02 PegaCardSdVisaInterlink: PegaCardSdAdvisorVisaCanada:04-03 PegaCardSdAdvisorVisaCanada:04-03 PegaCardSdVisaCanada: PegaCardSdAdvisorVisaUS:04-02 PegaCardSdAdvisorVisaUS:04-02 PegaCardSdVisa:

65 61 All Associations, All Regions Visa All Regions Visa US and Canada PegaCardSdVisaAP: PegaCardSdVisaAP: PegaCardSdAdvisorVisa:04-03 PegaCardSdVisaUS: PegaCardSdVisaUS: PegaCardSdConfig:04-03 PegaCardSdVisaCEMEA: PegaCardSdVisaCEMEA: PegaCardSdAdvisor:04-03 PegaCardSdVisaInterlink: PegaCardSdVisaInterlink: PegaCardSdIssuer:04-01 PegaCardSdVisaLAC: PegaCardSdVisaEurope: PegaCardSdVisaCanada: PegaCardSdVisa: PegaCardSdAdvisorVisa:04-03 PegaCardSdMasterCard: PegaCardSdAdvisorMasterCard:04-04 PegaCardSdAMEX:04-04 PegaCardSdVisaLAC: PegaCardSdVisaEurope: PegaCardSdVisaCanada: PegaCardSdVisa: PegaCardSdAdvisorVisa:04-03 PegaCardSdConfig:04-03 PegaCardSdAdvisor:04-03 PegaCardSdIssuer:04-01 PegaCardSdAdvisorAMEX:04-02 PegaCardSdConfig:04-03 PegaCardSdAdvisor:04-03 PegaCardSdIssuer:04-01 Step 2: Update the Class Inheritance Since the new Application is built on existing Smart Dispute Framework, a large number of classes that are generated by Application Accelerator have direct references to the MyCosample application that is provided by the framework. You need to update the directed inheritance of all these classes from MyCo specific classes to PegaCard specific classes. 1. Update the directed inheritance for the FW-Work class from MyCoCardSD-Work to PegaCard-Sd-Dispute- 2. Update the directed inheritance for the FW-Work-Claim class from MyCoCardSD- Work-Claim to PegaCard-Sd-Claim- 3. Update the directed inheritance for the FW-Work-Dispute class from MyCoCardSD- Work-Dispute to PegaCard-Sd-Dispute- 4. Update the directed inheritance for the FW level Association/Region classes from MyCo specific Association classes to PegaCard specific Association/Region classes. Smart Dispute for Issuers Implementation Guide

66 62 Smart Dispute for Issuers Implementation Guide For example, update the directed inheritance for the FW-Work-Dispute-AMEX class from MyCoCardSd-Work-Dispute-AMEX to PegaCard-Sd-Dispute-AMEX- Step 3: Copy the MyCo Rules into the target Framework application A large number of rules must be copied from the MyCo sample application into the target Framework application. When each rule is copied, make sure to follow best practices when choosing the correct ruleset from the Framework. The following table lists all of the rules in the MyCoCardSd Ruleset. Class Name Description Activity MYCOCARDSD-WORK!NEWDISPUTECASEENTRY Open a new case from a customer Activity PEGACARD-SD-CLAIM-!SNAPDEMO_ACCOUNTSEARCH Account Search (SQL) Activity PEGACARD-SD-CLAIM-!SNAPDEMO_STEPPAGE Determine which StepPage to Pass Next Activity Case Type MYCOCARDSD-WORK!PYDEFAULT CaseType for this work type Control DISPLAYRCFORREPORT display Reason Code Control DISPUTETYPERADIOS Dispute radio buttons Control YESORNORADIOS Yes/No radio buttons Correspondence PEGACARD-SD-DISPUTE-!RESOLVEDCARDHOLDERFAVOR!MAIL Dispute Resolved cardholder favor Data Transform MYCOCARDSD-WORK-CLAIM!PYPREVIEW pypreview Data Transform MYCOCARDSD-WORK-DISPUTE!PYPREVIEW pypreview Data Transform PEGACARD-PARTY-BANK! Model for creating a new party Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer

67 63 Class Name Description Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer Data Transform PEGACARD-PARTY-BANK!BIN Model for creating a new party for issuer Data Transform PEGACARD-SD-DISPUTE-!PYDEFAULT Model pydefault for PegaCard-Sd-Dispute- Decision Tree PEGACARD-SD-DISPUTE-!ISPROVISIONALCREDIT Check for the Provisional Credit Decision Tree PEGACARD-SD-DISPUTE-!ISWRITEOFF Check for the writeoff Field Value MYCOCARDSD-WORK!PYSTATUSWORK!PENDING- MEDIATION Pending-Mediation Financial Adjustment Rule PEGACARD-SD-DISPUTE-!ADJUST!DRFOREIGNEXCHANGECROTHERACCTS 1st ChargeBack Flow MYCOCARDSD-WORK!FINWRITEOFFAGEDMONTHLY Write-off an old suspense item Flow MYCOCARDSD-WORK-CLAIM!NEWDISPUTE Create New Dispute Flow MYCOCARDSD-WORK-CLAIM!NEWMULTITXNS Dispute Multiple Transactions Flow Action PEGACARD-SD-DISPUTE-!INITIATEINBOUNDPREARBITRATION Initiate inbound Pre-Arbitration Response Flow Action PEGACARD-SD-DISPUTE-!INVOKEINBOUNDARBITRATION Invoke Inbound Arbitration process Harness MYCOCARDSD-WORK-CLAIM!NEW Perform form for work object HTML DATA-GADGET!FINDWORKBYIDQUERYNEXT Find existing Work by ID or query, or get next HTML DATA-GADGET!MYGROUPSD Links to manage group's work HTML DATA-GADGET!SUPGROUPSD Links to manage group's work HTML DATA-PORTAL!FULLHEADER Header for full screen Portal HTML PEGACARD-SD-CLAIM-!WORKCLASSOPTIONS COMMENT OUT list of classes that are not Cover or FolderClasses. List View RULE-OBJ-FLOWACTION!LOOKUPLIST!ALL Look Up List View List View RULE-OBJ- PROPERTY!LISTOFPROPERTIESINPEGAAPP!ALL Property List Map Value MYCOCARDSD-WORK-!CHARTOFACCTS Chart of Accounts Map Value MYCOCARDSD-WORK-!FINCHARTOFACCTS Chart of Accounts Smart Dispute for Issuers Implementation Guide

68 64 Smart Dispute for Issuers Implementation Guide Class Name Description Map Value MYCOCARDSD-WORK!FINWORKPOOLCLASSES Classes to use for a Work Pool Map Value MYCOCARDSD-WORK!WORKPOOLCLASSES Classes to use for a Work Pool Map Value PEGAAPP-STEP-!FINVERIFICATIONFLOWBYAMOUNT Amount Thresholds for Verification Levels Map Value PEGACARD-SD-DISPUTE-!FINWORKBASKETS Accounting Workbaskets Map Value PEGACARD-SD-DISPUTE-!MERCHANTCATDESC Long Descriptions for Merchant Category Map Value PEGACARD-SD-DISPUTE-!SPECIALCONDINDFIRSTDESC Special Condition Indicators Desc - First Portal MYCODISPUTEENTRYUSER Desktop display for System Admin Portal MYCODISPUTEFRAUDPROCESSINGUSER Desktop display for Dispute Entry Portal MYCODISPUTEMANAGERUSER Desktop display for Supervisor Portal MYCODISPUTEPROCESSINGUSER Desktop display for Dispute Entry Portal MYCODISPUTESIMPLEENTRYUSER Desktop display for Dispute Entry Portal MYCODISPUTESUPERVISORUSER Desktop display for Supervisor Property EMBED-REASONCODE-TIMEFRAME!CONDITION controls whether a particular time frame is applied Property MYCOCARDSD-WORK!NEWPROP New Prop Property MYCOCARDSD-WORK!PYID Work Item Property MYCOCARDSD-WORK!TESTING Date returned: Property PEGACARD-SD-DISPUTE-!INBOUNDPRECOMPLIANCEGRANTEDOPTION To hold the option for granted Inbound pre compliance Property RULE-!PYCIRCUMSTANCETYPE pycircumstancetype Report Definition MYCOCARDSD-WORK-CLAIM!RELATEDCLAIMCASES Related Claim Cases Report Definition Report Definition MYCOCARDSD-WORK- DISPUTE!CHARGEBACKSBYREASONCODE MYCOCARDSD-WORK- DISPUTE!DISPUTESAPPROACHINGTIMEFRAMES (Change RD Category to ChargeBacks) Display Report for Chargebacks by Reason code Disputes Approaching Timeframes Report Definition MYCOCARDSD-WORK-DISPUTE!DRILLDOWNREPORT Item Details Report Definition MYCOCARDSD-WORK-DISPUTE!RELATEDDISPUTELIST Related Dispute List Report Definition MYCOCARDSD-WORK- DISPUTE!REPRESENTMENTSBYCHARGEBACKOPERATOR Representments By Chargeback Operator

69 65 Class Name Description Report Definition Report Definition MYCOCARDSD-WORK- DISPUTE!REPRESENTMENTSBYREASONCODE MYCOCARDSD-WORK- DISPUTE!WRITEOFFSBYREASONCODE Display Report for representments by Reason code Display Report for Writeoffs by Reason code Section PEGAAPP-TXN-!FINTXNDETAIL FinTxnDetail Summary View MYCOCARDSD-WORK- DISPUTE!RESOLUTIONOFSUSPENSE!ALL ResolutionOfSuspense Step 4: Remove the MyCo ruleset references from the SmartDispute_Install Application Rule After all of the needed rules from the MyCo sample application have been copied into the target application the MyCo rulesets are no longer needed in the current application. Remove all MyCo rulesets from the Application rule immediately. Step 5: Add new Roles to the Access Group Once you have finished building the new Application, in the newly created Access Group, the following Riles should be added. Failure to do this will result in transaction errors in the dispute process. Smart Dispute for Issuers Implementation Guide

70 66 Smart Dispute for Issuers Implementation Guide Chapter 5: Personalizing Smart Dispute This chapter describes areas of Smart Dispute that you may want to modify, and how to set up some functionality for your organization. The topics included in this chapter are: 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) 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 (Figure 5-1).

71 67 Figure Selecting Verify Option on the Correspondence Rule Form 2. Select Verify from the After Create field on the Corr tab of the Correspondence rule form (Rule-Obj-Corr). Note: PegaRULES Process Commander Application Developer 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 service level named PegaCard-Sd-Claim-.WaitToCloseCover starts an activity named AllCoveredResolvedCheck that determines which Cover letters to send and at what time. This service level runs every 24 hours until all disputes (covered objects) have been resolved. 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. Smart Dispute for Issuers Implementation Guide

72 68 Smart Dispute for Issuers Implementation Guide 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 non-resolved 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, Follow-up/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. Click the App Explorer tab. 2. Choose PegaCard- Sd- Claim- from the drop down select. 3. Navigate to Process > Flow and click the name of the NewWork flow. The Flow form appears, displaying the NewWork flow (Figure 5-2).

73 69 Figure The New Work Flow 4. Click Save As. The Save As form appears. 5. Select your RuleSet name from the selection box and click Save As. Smart Dispute for Issuers Implementation Guide

74 70 Smart Dispute for Issuers Implementation Guide 6. Double-click the flow image to open the flow in Visio (Figure 5-3). Figure Visio Flow for NewWork 7. Remove SendResolutionLetter from the Visio Flow. 8. Click Save and then close the form. Removing the Acknowledgement, Affidavit, and Follow-Up Letters The Acknowledgement, Affidavit, and Follow-Up letters are processed by the SLAOpenCoverageProcessing activity. If you remove the first three steps in this activity, then letters are no longer processed automatically. To remove the letters: 1. Click the App Explorer tab 2. Choose PegaCard-Sd-Claim- from the drop down select box. 3. Navigate to Technical > Activity and click the + symbol to expand the Activity node. 4. Click the SLAOpenCoveredProcessing activity. The Activity form appears (Figure 5-4).

75 71 Figure SLAOpenCoveredProcessing Activity 5. Click Save As. The Save As form appears. 6. Select your RuleSet name from the selection box and click Save As. 7. For each letter you wish to remove, click that row and then click Delete. 8. 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 conditions: 1. Click the App Explorer tab 2. Choose PegaCard- Sd-Claim- from the drop down select box. 3. Navigate to Technical > Activity and click the + symbol to expand the Activity node. 4. Click the SLAOpenCoveredProcessing activity. The Activity form appears (Figure 5-5). Figure SLAOpenCoveredProcessing Activity 5. Click Save As. The Save As form appears. 6. Select your RuleSet name from the selection box and click Save As. Smart Dispute for Issuers Implementation Guide

76 72 Smart Dispute for Issuers Implementation Guide 7. Click the red arrow next to the step you want to modify. The detail information for that step appears (Figure 5-6). Figure Activity Step Details 8. Replace the template identified in the CorrName field with the name of the correspondence template you want sent to the cardholder. 9. Click Save and close the form. 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:

77 73 Alternate Payment Document Cardholder letter Copy transaction receipt Copy transaction receipt missing imprint or signature For any letters you wish to create, make a copy of the document type rule and save it to your RuleSet. Follow the instructions below to add automatic correspondence to this process. To modify the document type: 1. Click the App Explorer tab 2. Choose Rule- PegaCard- DocType from the drop down select box. 3. Click the Rule-PegaCard-DocType link. A list of document types appears. 4. Click the document type you wish to modify. The Document Type form appears. Figure 5-7 shows a sample of a CardholderLetter document type. Figure Sample Document Type 5. Click Save As. The Save As form appears. 6. Select your RuleSet name from the selection box and click Save As. 7. Enter a stream name (such as AcknowledgeClaim-), a Corr Type (such as Mail), and the Party (such as cardholder). See chapter 3 for a list of stream names and mail correspondence templates. 8. Click Save and close the form. Smart Dispute for Issuers Implementation Guide

78 74 Smart Dispute for Issuers Implementation Guide 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. 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: 1. Click the App Explorer tab. 2. Choose PegaCard- Sd- Dispute- from the drop down select box. 3. Click the + next to the Decision node to expand the node. 4. Click Map Value. A list of Decision Map rules appears. 5. Click the + next to OnUs, and then click the instance that is in the PegaCard-Sd-Disputeclass. A Map Value form appears (Figure 5-8). Figure OnUs Map Values 6. Click Save As. The Save As form appears. 7. Select ClassName-Sd-Dispute- from the Class Name list (where ClassName is your toplevel class name), select your RuleSet from the selection box, and then click Save As. A Map Value form appears. 8. On the Matrix tab, click in a field and then click Insert Row. Add your BIN numbers and set their values to Y. 9. 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

79 75 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. To modify the TalkOff flow instance: 1. Click the App Explorer tab. 2. Choose PegaCard- Sd- Dispute- from the drop down select box. 3. Click the + next to User Interface to expand the node. 4. Click Flow Action. A list of Flow Action rules appears. 5. Click the + sign next to the InvokeTalkOff rule, and then click the instance in the PegaCard- Sd-Dispute- class. A Flow Action form appears (Figure 5-9). Figure TalkOff Flow Definition 6. Click Save As. The Save As form appears. 7. Select ClassName-Sd-Dispute- from the Class Name list (where ClassName is your toplevel class name), select your RuleSet from the selection box, and then click Save As. The Flow Action form appears. 8. Open the ActionInvokeAdvisor Harness in PegaCard-Sd-Dispute, and save into your target class as per step #7.. The Harness Section form appears (Figure 5-10). Smart Dispute for Issuers Implementation Guide

80 76 Smart Dispute for Issuers Implementation Guide Figure Harness Section for ActionInvokeTalkOff 9. Click the HTML tab and edit the text as necessary. 10. Click Save and close the form. 11. In the Flow Action form, click Save. 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.

81 77 To change a scoring rule: 1. Click the App Explorer tab. 2. Choose Rule- PegaApp- Search- Scoring from the drop down select box. 3. Click the Rule-PegaApp-Search-Scoring link. A list of rules appears. 4. Select the instance of DuplicateScore in the PegaCard-Sd-Dispute- class. A Scoring Rule form appears (Figure 5-11). Figure Modifying a Scoring Rule 5. Click Save As. The Save As form appears. 6. Select ClassName-Sd-Dispute- from the Class Name list (where ClassName is your toplevel class name), select your RuleSet from the selection box, and then click Save As. The rule form appears. 7. 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. 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. 8. 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 Smart Dispute for Issuers Implementation Guide

82 78 Smart Dispute for Issuers Implementation Guide 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. 9. 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 Figure 5-11, 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. 11. Click Save and close the form. Modifying SnapStart for Smart Dispute The SnapStart activity allows users to bypass all the HTML screens and generate a cover and a work object, depending upon the parameter values supplied. The parameters currently defined in Smart Dispute are: InsClass Class to create FolderType Folder type fromsearchportal From which search portal the information comes DetailClass Class of the item being affected AccountNumber Account number for the transaction AcquirerReferenceNumber Reference number of the supplier InsClass and FolderType are required, and a user must enter either an account number or an acquirer reference number. Smart Dispute performs different activities depending upon what users enter (account number or acquirer reference number): If users enter both the account number and the acquirer reference number, a cover and work object are automatically generated, and the system checks for potential duplicates. If a potential duplicate is found, the user is prompted to resolve the duplicate; otherwise, the user is taken to the Qualify Dispute assignment screen.

83 79 If users enter only the acquirer reference number, a cover and work object are automatically generated, and the user is taken to the Qualify Dispute assignment screen. If users enter only the account number, an account search screen appears and displays a list of transactions. Users select a transaction and then create the dispute following the defined workflow. To change the SnapStart activity 1. Click the App Explorer tab. 2. Choose PegaCard- Sd- Dispute from the drop down select box. 3. Click the + sign next to the Technical node to expand it, and click Activity. A list of rules appears. 4. Click SnapStart. The SnapStart activity screen appears. 5. Click Save As. The Save Rule Instance under new key form appears. 6. 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. 7. Select the Parameters tab and modify the defined parameters (Figure 5-12). Figure SnapStart Activity Parameters Screen 8. Edit the parameters as necessary and then click Save. Smart Dispute for Issuers Implementation Guide

84 80 Smart Dispute for Issuers Implementation Guide 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, you need to create and use new work object classes. The DetermineWorkObject activity determines what class type of work object to create for each dispute. The property InterchangeSourceID 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) 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: - MyCoCardSd-Work-Dispute- (generic) - MyCoCardSd-Work-Dispute-Association -International - MyCoCardSd-Work-Dispute-Association -US Modifying Existing Processing The following tasks 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, if you create a new Reason Code Advisor class. 4. Optionally, if they are the closest models to use, modify the Decision Tree rules GenericTransDT and GenericDisputeDT, which determine the transaction page and dispute page, respectively, for generic transactions.

85 81 In the following example, existing processing is modified to process transactions for Japanese Card cards. The new work object class created is MyCoCardSd-Work-Dispute-Card-Japan. To modify the decision tree: 1. Click the App Explorer Tab. 2. Choose PegaCard-Sd-Dispute- from the drop down select. 3. Click the + next to the Decision node to expand it. 4. Click Decision Tree. A list of decision trees appears. 5. Select VisaDisputeDT (or MCDT). The Decision Tree form appears (Figure 5-13). The rule is in a locked RuleSet, so you must save it to your own RuleSet before you can modify it. Figure VisaDisputeDT Decision Tree 6. Click Save As. The Save As form appears. 7. Select ClassName-Sd-Dispute- from the Applies To list (where ClassName is your top-level class name), select your RuleSet from the selection box, and then click Save As. The rule is saved into your RuleSet, and you can now modify it. Smart Dispute for Issuers Implementation Guide

86 82 Smart Dispute for Issuers Implementation Guide 8. 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 MyCoCardSd- Work-Dispute-Card-Japan. 9. Click Save and close the form. Creating a New Association The following tasks define processing logic to support a new association: 1. Create new work object classes for transactions and disputes. 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 Decision Tree rules GenericTransDT and GenericDisputeDT, 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 MyCoCardSd-Work-Dispute-CardMan MyCoCardSd-Work-Dispute-CardMan-Canada To modify the Map Value rules: 1. Click the Class Explorer tab. 2. Choose Rule- from the drop down list. 3. Click the + next to Obj-, then click MapValue. A list of Map Value rules appears. 4. Click on the row for the AssociationDescMatrix rule. The Map Value form appears (Figure 5-14). The rule is in a locked RuleSet, so you must save it to your own RuleSet before you can modify it.

87 83 Figure AssociationDescMatrix Map Value 5. Click Save As. The Save As form appears. 6. Select ClassName-Sd-Dispute- from the Applies To list (where ClassName is your top-level class name), select your RuleSet from the selection box, and then click Save As. The rule is saved into your RuleSet, and you can now modify it. 7. Edit the map value so that the Interchange Source ID 13 maps to CardMan Credit Cards. 8. When you finish, click Save and close the form. 9. Repeats steps 3 to 7 for the Map Value rule TransDecTreeMatrix, so that the Interchange Source ID 13 maps to CardManTransDT. 10. Repeats steps 3 to 7 for the Map Value rule DisputeDecTreeMatrix, so that the Interchange Source ID 13 maps to CardManDisputeDT. To create decision tree rules: The following procedure uses an existing decision tree as a template. 1. Click the Class Explorer Tab. 2. Choose Rule- from the drop down select box. 3. Select Declare- > DecisionTree. A list of decision trees appears. 4. Select VisaDisputeDT. The Decision Tree form appears (Figure 5-13). The rule is in a locked RuleSet, so you must save it to your own RuleSet before you can modify it. Smart Dispute for Issuers Implementation Guide

88 84 Smart Dispute for Issuers Implementation Guide Figure The VisaDisputeDT Decision Tree 5. Click Save As. The Save As form appears. 6. Select ClassName-Sd-Dispute- from the Applies To list (where ClassName is your top-level class name), rename the decision tree CardManTransDT, select your RuleSet from the selection box, and then click Save As. The rule is saved into your RuleSet, and you can now modify it. 7. Edit the decision tree to always return the string PegaCard-Interface-Transactions- CardMan. 8. When you finish, click Save and close the form. 9. Repeats steps 3 to 7 to create the Decision Tree rule CardManDisputeDT, so that the rule returns the string MyCoCardSd-Work-Dispute-CardMan-Canada if the cardholder is Canadian, and the string MyCoCardSd-Work-Dispute-CardMan otherwise. Defining and Processing New Reason Codes A Reason Code rule represents the chargeback requirements for a reason code/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. The following tasks define and process a new reason code:

89 85 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 (see page 81). To create a new reason code: 1. Click the App Explorer tab. 2. Choose Rule- PegaCard-ReasonCode from the drop down select box. 3. Click the Rule-PegaCard-ReasonCode link. A list of reason codes appears. 4. Click New. The New form appears. Select the appropriate class name from the Class Name field, 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. 5. Click Create. The Reason Code form appears (Figure 5-16). Figure Reason Code Form 6. Complete the fields of the tabs as described in Figure When you finish, click Save and close the form. Field Short Description Description Required. Description of the reason code. Smart Dispute for Issuers Implementation Guide

90 86 Smart Dispute for Issuers Implementation Guide Field Timeframes Tab Primary Timeframe Primary Applies To Primary Condition Secondary Timeframe Secondary Applies To Secondary Condition Documents Tab Inbound Documents Label Inbound Documents Property Inbound Documents Required? Inbound Documents Type Inbound Documents Criteria Outbound Documents Label Description A Reason Code rule has two timeframes, primary and secondary. A primary timeframe is the time period within 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 within 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. 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.

91 87 Field Outbound Documents Property Outbound Documents Required? Outbound Documents Type Outbound Documents Criteria Document Indicator Description 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: a. 0 No supporting documentation provided b. 1 Supporting documentation is to follow c. 2 Invalid Reference Number Documentation Not Required/Received d. 3 Incompatible/Invalid Reference Number Documentation Required e. 4 Supporting Documentation Not Received Details Tab Ancillary Questions Message Text Default case to fraud? Next Tab Retrieval Required? Retrieval Flow Chargeback Flow Second First Chargeback? 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. 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. Smart Dispute for Issuers Implementation Guide

92 88 Smart Dispute for Issuers Implementation Guide Field Chargeback Amount Limitation Limits Tab ReasonCode Limitations History Tab Description 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. Figure Fields on the Reason Code Form To create a new ancillary question: 1. Click the Class Explorer tab. 2. Choose Rule- from the drop down select box. 3. Select PegaCard- > ReasonCode- > Question. A list of ancillary questions appears. 4. Click New. The New form appears. 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 (Figure 5-18). Figure Ancillary Question Form 6. Complete the fields of the tabs as described in Figure When you finish, click Save and close the form. Field Details Tab Display HTML Category 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.

93 89 Field Description Validation Sets the requirements for the question, the Rule properties that would be validated against, and whether or not they are required. Control Tab Lists When rules that would be applied to the ancillary question. Whens When rule defined on the same class as the Ancillary Question. History Tab Enter a detailed description of the ancillary question and information on how it is used. To review the Save history, click History Details. Figure Fields on the Ancillary Question Form 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 Class Explorer tab. 2. Choose Rule- from the drop down select box. Select HTML- > Property. A list of HTML Property rules appears. The Ruleset location will vary according to the Associations that have been installed. 3. Select the instance Category. The HTML Property form appears (Figure 5-20). The rule is in a locked RuleSet, so you must save it to your own RuleSet before you can modify it. Smart Dispute for Issuers Implementation Guide

94 90 Smart Dispute for Issuers Implementation Guide Figure HTML Property Form for Category 4. Click Save As. The Save As form appears. 5. 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. 6. Edit the HTML code as necessary to include the new category. 7. 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 will need to define new bank identification numbers (BINs). One bank may require multiple BINs. BINs are defined in a Model rule (an instance of Rule-Obj-Model) named BINnnnnnn, where nnnnnn is the issuer number. To define a new BIN: 1. Click the Class Explorer tab. 2. Choose Rule- from the drop down select box. 3. Select Data Model - > Data Transform. A list of Data Transform rules appears. 4. Filter the list where the Name includes BIN, select a Data Transform rule. The Data Transform form appears (Figure 5-21). The rule is in a locked RuleSet, so you must save it to your own RuleSet before you can modify it.

95 91 Figure Model Form 5. Click Save As. The Save As form appears. 6. 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. 7. Edit the list of properties as necessary to define the new issuer. 8. When you finish, click Save and close the form. Smart Dispute for Issuers Implementation Guide

96 92 Smart Dispute for Issuers Implementation Guide Chapter 6: Working With the 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 must be defined in the rule ClassName-Data-InternalAccount, where ClassName is your toplevel class. Internal accounts are referred to in the Chart of Accounts. You must create your own internal accounts, one or more for the following kinds: Payable Receivable WriteOff WriteOff2 Note: The product includes sample internal accounts in the MyCoCardSd-Data- InternalAccount class, identified by the prefix MyCo in the Class Explorer. You

97 93 can look at them by selecting MyCoCardSd- > Data- > InternalAccount. The figures in this chapter show examples from SampleCo. To create a new internal account: 1. Click the App Explorer tab. 2. Choose ClassName- Data-InternalAccount from the drop down select box, where ClassName is your top-level class name. 3. Click the ClassName- Data-InternalAccount link. The instances list appears. 4. Click New. The New Rule form appears (Figure 6-1). Figure New Rule Form for Internal Accounts 5. In the URI field, enter a key of your choosing (it must be unique, and spaces are not allowed) and click Create. The Internal Account form appears (Figure 6-2). Figure Creating an Internal Account 6. Enter values in the Account Type, Account Number, Bank Number, and Account Name fields. Follow the guidelines below for entering values: Account Type is freeform, with no restrictions. Account Number can be a maximum of 16 numeric characters. Bank Number must be numeric with no maximum number of characters. Account Name is freeform, with no restrictions. Smart Dispute for Issuers Implementation Guide

98 94 Smart Dispute for Issuers Implementation Guide 7. Click Save and close the form. Setting Up Accounting Party Data Smart Dispute party data tables are referenced by the product to look up and populate data in claims and accounting transactions. You must copy Data- classes to provide a destination for the results of data input using interfaces to existing data systems. The Data- classes identify data sources and other key variables. You must also specify Party- classes, which specify the organizations you deal with. (You do not have to copy History- classes because the system automatically generates them.) To copy Data- classes: 1. Go to the start page of the Developer Portal and click the Monitor Activity slice. 2. In the Rule Reports section, click the Rule Modification by Rule Type, RuleSet link. A query form appears as shown in Figure 6-3. Figure Query Form 3. Fill in the fields as follows (the fields are case-sensitive): In the Class row, enter Rule-Obj-Class in both columns. In the RuleSet row, enter MyCoCardSd in both columns. In the Condition field for the Version row, select Is Null. 4. Click Execute Query. The Rule Count and Modification Summary by Class, RuleSet report appears. 5. Click the plus sign to the left of Class (beneath Expand All). A row displaying RuleSet: MyCoCardSd appears (Figure 6-4).

99 95 Figure Rule Count and Modification Summary by Class, RuleSet 6. Click the RuleSet: MyCoCardSd link. A list of class rules appears. Figure Rule Instance List for Count by Class, RuleSet, Version 7. Select the row displaying Rule-Obj-Class: MyCoCardSd-Data-. A window containing Summary fields appears. 8. Click Open. The data class form appears (Figure 6-6). Figure Rule Instance List for Count by Class, RuleSet, Version 9. Click Save As. The Save As window opens with the RuleType field filled in. 10. Change the class name from MyCoCardSd-Data- to ClassName-Data-, where ClassName is the name of your top-level class. 11. Select your application RuleSet from the RuleSet selection box and then click Save As. The ClassName-Data- class form appears. Smart Dispute for Issuers Implementation Guide

100 96 Smart Dispute for Issuers Implementation Guide 12. Click Save. 13. Repeat steps 8 through 12 for each Rule-Obj-Class that starts with MyCoCardSd-Data-. Note: For the data rule MyCoCardSd-Data-InternalAccount, ensure that the value in the Inherit From (Parent) field is PegaApp-Party-InternalAccount. To copy Party- classes: 1. Go to the start page of the Developer Portal and click the Monitor Activity slice. 2. In the Rule Reports section, click the Rule Modification by Rule Type, RuleSet link. A query form appears as shown in Figure 6-3. Figure Query Form 3. Fill in the fields as follows (the fields are case-sensitive): In the Class row, enter Rule-Obj-Class in both columns. In the RuleSet row, enter PegaCard in both columns. In the Condition field for the Version row, select Is Null. 4. Click Execute Query. The Rule Count and Modification Summary by Class, RuleSet report appears. 5. Click the plus sign to the left of Class (beneath Expand All). A row displaying RuleSet: PegaCard appears. 6. Click the RuleSet: MyCoCardSd row. A list of class rules appears. 7. Select the row displaying Rule-Obj-Class: PegaCard-Party-. Summary fields appear at the bottom of the window. 8. Click Open. The party class form appears. 9. Click Save As. The Save As window opens with the Rule Type field filled in.

101 Change the class name from PegaCard-Party- to ClassName-Party-, where ClassName is the name of your top-level class. 11. Select your application RuleSet from the RuleSet selection box and click Save As. The ClassName- Party- class form appears. 12. Click Save. 13. Repeat steps 8 through 12 for each Rule-Obj-Class that begins with PegaCard-Party-. Defining the Chart of Accounts Smart Dispute maintains an internal list of accounts that your organization uses to track accounting transactions. This chart of accounts lets users 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 your organization uses. To define the chart of accounts: 1. Click the App Explorer tab. 2. Choose MyCoCardSd-Work from the drop down select box. 3. Click the + next to MyCoCardSd-Work- to expand the node. 4. Click Map Value from the selection box. A list of rules appears. 5. Click FinChartOfAccts. The Map Value form appears Figure 6-8. Figure Map Value Window 6. Click Save As. The Save As form appears. 7. Select ClassName-Work- 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. The Map Value form appears. Smart Dispute for Issuers Implementation Guide

102 98 Smart Dispute for Issuers Implementation Guide 8. Enter values in the rows and columns as follows: The Account column lists the codes referenced in the step rules Rule-PegaApp- Financial-Payable, Rule-PegaApp-Financial-Receivable, and Rule-PegaApp- Financial-Adjustment. Do not change these values unless you have overridden all step rules that refer to them. The Bank Number column refers to the keys of internal accounts. (Bank Number is synonymous with BIN number. You can have multiple banks with multiple accounts.) Use the Insert Column Before and Insert Column After buttons to create columns; you can also edit the map in Excel. 9. Click Save and close the form. Setting up Payment Types A payment type is associated with a debit or credit transaction in an accounting step. The payment type determines the following: The accounting cutoff time for the transaction Whether documents or automatic advices are to be generated and in what format The rule Rule-PegaApp-Financial-PaymentType defines payment types. The payment type is associated with a transaction in step rules. If your organization s transactions require documents different from the ones referenced in the supplied payment-type rules, or if you require different cutoff times, then create the Rule-Obj-Corr rule and Rule-PegaApp- Financial-Cutoff rules first and then copy the payment-type rule with the same name to your RuleSet. If you require new payment types, you can create your own and then update the step rules to reference them. To change payment types: 1. Click the App Explorer tab. 2. Choose Rule-PegaApp-Financial-PaymentType from the drop down select box. 3. Click the Rule-PegaApp-Financial-PaymentType link. A list of rules appears. 4. Select the payment type you want to change. The Payment Type form appears (Figure 6-9).

103 99 Figure Modifying a Payment Type 5. Click Save As. The Save As form appears. 6. Select ClassName-Work- 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. The Payment Type form appears. 7. To change the cutoff rule, enter a new name. (Cutoff rules are discussed later in this chapter.) 8. Enter new values for the Stream Name and Corr Type fields which, together with the Class Name, identify a correspondence template. 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. 9. Select Required if you want the document to be generated for all transactions that use this payment type. If you leave the box unchecked, the document is not generated for automatic processing, but users will have the option to generate it during manual processing. 10. Click Save and close the form. Accounting Step Rules Accounting step rules define what makes up an accounting entry (a set of debit and credit transactions). There are three accounting step rule classes, organized by the type of accounting steps: Rule-PegaApp-Financial-Adjustment: for adjustment Smart Dispute for Issuers Implementation Guide

104 100 Smart Dispute for Issuers Implementation Guide Rule-PegaApp-Financial-Payable: for payable suspense Rule-PegaApp-Financial-Receivable: for 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 suspense versus adjustment), and a Type that specifies a name for the particular rule. Figure 6-10 shows the Step tab of the Adjustment Rule window for the instance CrCardHolder in the class PegaCard-Sd-Dispute-. Figure Step Tab of Adjustment Rule Window Figure 6-11 shows the Transactions tab for the same instance; the screen is wide and you must scroll from left to right to see all the fields. These fields, and their use in creating new step rules, are described in detail in the following topics. Figure Transaction Tab of Adjustment Rule Window (Left and Right Sides)

105 101 Fields on the Adjustment Rule Form Figure 6-12 describes the fields in the Adjustment Rule form. Field Short Description Step Tab Class of the Step Activity for Verification Flow Model to create Step Validate Activity Likelihood Transactions Tab Description Required. Short description of the rule. This value is displayed during manual accounting in the list of step rules the user can select. The class of the page that holds the Step data. Specify a Rule-Obj-class name that is a concrete class and is a child of class PegaApp- Step-. 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 allows you to 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 used to preselect the most likely step rule (the one with the highest number) during the manual flow actions that create accounting steps. Smart Dispute for Issuers Implementation Guide

106 102 Smart Dispute for Issuers Implementation Guide Field Group Description Specifies if 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 only one transaction can be chosen). The first transaction in the group is selected in automatic processing, so the order is significant. Label DR / CR Role Txn Class Pymt Type Note that Smart Dispute does not use groups because there is a singe internal account for Receivable, Write-Off, etc. Appears in the window during manual accounting creation flow actions to indicate the name of the transaction. Indicates if 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 may be used to find or report on the transaction. The class of the page that holds the transaction data; specify a Rule-Obj-Class name that is a concrete class that is a child of class PegaApp-Txn-. Name of Rule-PegaApp-Financial- PaymentType rule to use for this transaction. The payment type rule associates correspondence with the transaction.

107 103 Field Default Account From Description Where to acquire 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.) Account From Value Protect Account? Default Amount From 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 value InternalAccount in the Map Value named WorkPoolClasses. 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. Smart Dispute for Issuers Implementation Guide

108 104 Smart Dispute for Issuers Implementation Guide Field Amount From Value Description 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 the property is on the top level of the work object page. Protect Amount? Security Tab Name Class When Name History Tab Figure Fields in the Adjustment Rule Window Specifies an actual amount number value if Default Amount From is Literal. Do not use quotation marks, $, or commas (that is, specify and not $1,000,00 or $ or ). Select 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. 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

109 105 highest likelihood and lets the user select any other valid step rules from a list of rules and their short descriptions. The standard straight-through processing flows (defined at PegaApp-Work) are: ReceivableOpenSTP ReceivableWriteOffSTP AdjustmentSTP ReceivableCloseSTP PayableOpenSTP AdjustmentWriteOffSTP ReceivableLowerSTP PayableCloseSTP To modify a step rule, you must save it into 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 defaulting 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, you must 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 may have a policy that adjustments above a certain amount must be verified by a manager. For example, you can choose not to require any 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. Note that no one user can verify a single 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 a MapValue named FinVerificationFlowByAmount, in the class PegaApp-Step, 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 it is. Smart Dispute for Issuers Implementation Guide

110 106 Smart Dispute for Issuers Implementation Guide To change amounts or verification levels 1. Click the Class Explorer tab. 2. Choose Rule- from the drop down select box. 3. Select Obj- > MapValue. A list of rules appears. 4. Click FinVerificationFlowByAmount. The FinVerificationFlowByAmount Map Value screen appears(figure 6-13). Figure Modifying Verification Levels 5. Click Save As. The Save As form appears. 6. Select ClassName-Sd-Dispute- from the Applies To list (where ClassName is your top-level class name), select your RuleSet from the selection box, and then click Save As. The verification flow is saved into your RuleSet. 7. Edit the rule as follows: To delete a verification level, click in that row and then click the Delete Row button to the right of the row. (You cannot delete the Default row.) To change a verification amount threshold, double-click a value and enter a new one. 8. Click Save. Cutoff Times Your organization may 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 Rule-

111 107 PegaApp-Financial-Cutoff, uses a warning time and a cutoff time such that all times of day within the rule are not past cutoff. If your organization requires different cutoff times for different payment types, you must create new cutoff rules in your RuleSet and update your Rule-PegaApp-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 a Rule- PegaApp-Financial-Cutoff rule named Settlement can define the cutoff times. Each payment type sent to the card processing system for settlement can reference the Settlement cutoff rule in Rule-PegaApp-Financial-PaymentType. When a deadline or processing window changes, you can update the Settlement rule and all payment types that reference it 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), users see a yellow clock icon next to any transaction past its warning time or a red clock next to any transaction past its cutoff time (Figure 6-19). Figure Past-Goal and Past-Cutoff Warnings in the User Interface To change the default cutoff rule: 1. Click the Class Explorer tab. 2. Choose Rule- from the drop down select box. 3. Select PegaApp- > Financial- > Cutoff. A list of rules appears. 4. Click the Default instance. The Cutoff Rule form appears (Figure 6-20). Smart Dispute for Issuers Implementation Guide

112 108 Smart Dispute for Issuers Implementation Guide Figure Modifying the Cutoff Rule 5. Click Save As. The Save As form appears. 6. Change the name if necessary (keep the same name if you are modifying the rule, or rename it if you are creating a new rule), select your RuleSet name from the selection box, and then click Save As. 7. Edit the Warning Time and Cutoff Time as necessary. Use the 24-hour notation format hhmmss, or clear the field to remove the warning or cutoff time. 8. Click Save and close the form. 9. Close the Cutoff Rule window. 10. If you created a new rule, reference it in your PaymentType rules. New Suspense Accounting In this release we have provided an opportunity for customers to more finely control suspense accounting. In prior releases, the sum total of an open suspense transaction would be written to the Outstanding and Suspense Balance of the work item on pyworkpage. This would be true even if the Open suspense step contained non-suspense transactions. For example if an Open step contained the following: DR Suspense Receivable DR Fee Reversal CR Customer Account 150/USD 35/USD 185/USD 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. To avoid writing off the 35/USD fee reversal, assuming full recovery of the 150/USD receivable, customers tended to split the steps into a receivable open for the 150/USD and

113 109 a fee adjustment for the 35/USD. This had the potential of resulting in 2 separate credits to the customer. For this release, we thought it appropriate to provide an option for customers to create one accounting step that would correctly account for the suspense balances and provide a single credit to the customer. Using the same open accounting step example: DR Suspense Receivable DR Fee Reversal CR Customer Account 150/USD 35/USD 185/USD The Suspense and outstanding balance would be 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 suspense accounting you will have to add some configuration elements as follows: 1. The toggle to turn on new suspense accounting is set in a dynamic system setting: a. Data-Admin-System-Settings b. Owning Rule Set PegaAppFin c. Purpose: NewSuspenseAccounting d. Value: true (triggers usage, false or blank turns it off) 2. Update Internal Accounts used by FinChartofAccts Instances of PegaApp-Party- InternalAccount and add a value for General Ledger Account Type a. A value of suspense will mark the account as available for New Suspense Accounting Smart Dispute for Issuers Implementation Guide

114 110 Smart Dispute for Issuers Implementation Guide 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. 5. 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-PegaApp-Financial-Cutoff rule specified by the Rule-PegaApp-Financial-PaymentType. Depending on the type of transaction, the Rule- PegaApp-Financial-PaymentType specified in one of three step rules is checked: Rule-PegaApp-Financial-Adjustment Rule-PegaApp-Financial-Payable Rule-PegaApp-Financial-Receivable Before using the specified cutoff time, the system checks the calendar to verify if 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. 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-PegaApp-Financial-Cutoff class. 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-PegaApp-Financial-Cutoff class. You may need to 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 the date is a nonbusiness day.

115 111 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 may specify goal and deadline times in business days Accounting may only be posted on business days Calendars are stored as instances of the class Data-Admin-Calendar. 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. Calendars for are included; Figure 6-21 shows the 2006 calendar. Figure Calendar for 2006 Adjusting Automatic Chargeback When the rules determine that qualifications have been met for chargeback, Smart Dispute determines if an automatic chargeback should be initiated. To adjust automatic chargeback: 1. Click the App Explorer tab. Smart Dispute for Issuers Implementation Guide

116 112 Smart Dispute for Issuers Implementation Guide 2. Choose PegaCard-Sd-Dispute- from the drop down select box. 3. Click the + next to Technical to expand the node. 4. Click Activity. A list of rules appears. 5. Select DetermineAutomation. The Activity form appears (Figure 6-22). Figure Activity to Determine Automation 6. Click Save As. The Save As form appears. 7. Select ClassName-Sd-Dispute- from the Class Name list (where ClassName is your toplevel class name), select your RuleSet from the selection box, and then click Save As. 8. Click the Expand Method icon to see the method information (Figure 6-23). Figure Determine Automation with Method Information 9. In the Task Status field, enter Automatic to turn on the automatic chargeback feature, or Manual to turn it off. 10. Click Save and close the form.

117 113 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. In Smart Dispute, currency is defined as a numeric property (e.g. 840 for USD) and currency description (e.g. USD) as the java class currency qualifier. 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 Application Developer Help or the PDN) Figure 6-24 shows the major properties 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 Figure Currency Properties 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 upon which they are stored, and the source of the data (where the data is coming from). Property Clipboard Page Source Smart Dispute for Issuers Implementation Guide

118 114 Smart Dispute for Issuers Implementation Guide 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 TransactionCurrencyD pywp.accounttransaction Mapped Value esc AuthorizationAmount pywp.accounttransaction Table:Pcd_Transactions AuthorizationCurrency pywp.accounttransaction Table:Pcd_Transactions Code AuthorizationCurrency pywp.accounttransaction Mapped Value Desc 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 CommonCurrencyCon Rate pyworkpage BasicCurrencyConRate Figure Properties, Clipboard Pages, and Source Information 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 properties TransactionAmount and TransactionCurrency to explain how the currency is tracked and managed. Example: Smart Dispute gets the 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 writes the value to the TranactionCurrencyDesc.

119 115 Figure 6-26 through Figure 6-29 show examples of the rules that are either updated automatically by Smart Dispute or that you have to modify to so that Smart Dispute handles multi-currency transaction correctly. Figure Transaction Amount in Disputed Claim On the Definition tab of the Rule- > Obj- > Property- > TransactionAmount screen, you update the property rule to reflect a currency amount property stream. Figure 6-27 shows an example. Figure Transaction Amount Property Property Stream Setting On the Qualifiers tab of the Rule- > Obj- > Property- > TransactionAmount screen, you update pycurrency to identify where Smart Dispute should enter the value of the currency. Figure 6-28 shows an example. Smart Dispute for Issuers Implementation Guide

120 116 Smart Dispute for Issuers Implementation Guide Figure Transaction Amount Property Qualifier Setting Figure 6-29 shows the Map value currencies used by the Smart Dispute Figure Map Value Currency Setting 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. In the example on page 114, the transaction is 425 Euros and the posted amount is 850 USD, so the currency conversion rate is therefore Smart Dispute assumes that the chargeback amount is in the same currency as the posting amount, with the Associations managing the exchange of currencies between the Issuer/Cardholder and the Acquirer/Merchant. Users can adjust the dispute amount when entering the dispute details. Any adjustment to the dispute amount is automatically adjusted by the property named DisputeTransactionAmount, using the currency conversion rate provided. This property and its currency can then be passed to the association during the chargeback.

121 117 Figure 6-30 shows the original Dispute Amount of USD, the conversion rate, and the disputed transaction amount in GBP. Figure Case Details Figure 6-31 shows the updated dispute amounts. Figure Updated Dispute Details Figure 6-32 shows how Smart Dispute passes the change through to process the chargeback. Smart Dispute for Issuers Implementation Guide

122 118 Smart Dispute for Issuers Implementation Guide Figure Updated Dispute Details 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, etc.) BINs (Bank Issuer Numbers). A BIN is the first 6 digits of the account number. It is the key to association processing (transactions, Chargebacks etc.). In Smart Dispute, each of the Issuing BINs can have one of any default billing currencies. So, a global credit card issuer could have BINS denominated in USD, GBP, EUR, JPY, etc. 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 selecting the CheckCurrency Decision Tree (Figure 6-33).

123 119 Figure Decision Tree for Issuing Bin Currencies 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, Integrating Smart Dispute for more information about this database table. Setting up a New Currency Qualified Amount Property You can new currency types to Smart Dispute for use with multi-currency transactions following the procedures below. You must follow the naming convention shown below for the amount, currency, and currency description. <Property Name>Amount (e.g., TransactionAmount) represents the amount property name <Property Name>Currency (e.g., TransactionCurrency) represents the numeric value of the currency, for example 840 for USD <Property Name>CurrencyDesc (e.g., TransactionCurrencyDesc) represents the alpha (java name) of the currency, for example USD Smart Dispute for Issuers Implementation Guide

124 120 Smart Dispute for Issuers Implementation Guide Note: For this procedure, we are going to use the name SampleAmount as the property name.

125 121 To establish a new currency qualified property: 1. Copy the following properties: TransactionAmount to SampleAmount TransactionCurrency to SampleCurrency TransactionCurrencyDesc to SampleCurrencyDesc 2. Update the SampleAmountProperty Set the property stream name to currencyamount this tells the system to use this value for the currency Set the currency qualifier to SampleCurrencyDesc this tell the system to use this value for the currency 3. Update the currency type decision map to add all the currencies and their values. For example, 978=EUR (Euros). If the original currency value is alpha you also want set EUR =EUR. Set the SampleCurrency property to run through the decision map in an activity to verify you are getting the SampleCurrencyDesc value. Smart Dispute for Issuers Implementation Guide

126 122 Smart Dispute for Issuers Implementation Guide Chapter 7: Integrating Smart Dispute Smart Dispute integrates with your information systems to improve quality, productivity, and efficiency. Smart Dispute provides activities and flows to support interactions with external systems, databases, and Web sites. The topics in this chapter include: Creating integration activities Generating a data dictionary (list of properties) For detailed information about integrating your Smart Dispute system with other systems, see PegaRULES Process Commander Integrating with External Systems. Creating Integration Activities Each Activity or Flow contains one or more integration activities. These activities perform specific functions such as creating a case, searching for account information, or getting data from another system. The names of these activities start with either do or get. Activities can be used as utilities in flows to pass parameters, or they can be steps within another activity. Smart Dispute comes with sample integration activities and flows that you can modify or use as models for creating new integration activities. Figure 7-1 lists the activities you can copy to your RuleSets. After you save the activity to your RuleSet, you can make changes to retrieve or update data. Class PegaApp-Interface- Account PegaApp-Interface- BusinessUnit PegaApp-Interface- BusinessUnit PegaApp-Interface- BusinessUnit PegaApp-Interface- Contact Figure Activity Integration Data Integration Activity AppGetAccountInfoRefresh AppGetAdditonalBusinessDetails AppGetAdditonalBusinessFaxDetails AppGetAdditonalBusinessPhoneDetails AppGetNotesForContact

127 123 To create an integration activity: 1. Click the Manage Rules bar. 2. Select the class containing the integration activity (such as PegaApp- > Interface- > Account-) and then select Activity from the selection box. A list of rules appears in the workspace. 3. Select an integration activity. The Activity form opens; Figure 7-2 shows a sample activity (dordbsave). Figure Integration Activity 4. Click Save As. The Save As window opens. 5. Select your RuleSet name and Version and then click Save As. The Activity form appears. 6. Edit the rule as necessary; make sure the Activity Type (on the Security tab) is set to Connect. 7. Click Save. Generating a Data Dictionary You can create a data dictionary, or list of properties, from Smart Dispute using standard rules reports. To generate a data dictionary: Click the Pega home button. 1. Click the Process and Rules, Tools, Find Rules, Find by RuleSet Version and Rule Type link. A report of all Claims Repair classes appears. Smart Dispute for Issuers Implementation Guide

128 124 Smart Dispute for Issuers Implementation Guide 2. Click the Customize Summary Criteria link, which is below the report heading. The Customize Criteria page appears (Figure 7-6). Figure Customize Criteria Options 3. Select Class (pyclass) from the Field list, leave the Condition set to Is Equal, and enter Rule-Obj-Property in the Value field. 4. Click Submit. A report displays all RuleSets containing items of class Rule-Obj-Property. 5. Click the + sign next to MyCoCardSd to show the RuleSet versions. 6. Click the most recent RuleSet version to display a Rule-Obj-Property report (Figure 7-7). Figure Rule-Obj-Property Report 7. Optionally, click the Export to Excel button to export the class data to an Excel spreadsheet.