Smart Investigate For IssuerSmart Dispute Overview Smart Dispute is a comprehensive rules-based...

Smart Investigate For Issuer Implementation Guide

V6.3.3

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 02142-1590

Phone: (617) 374-9600 Fax: (617) 374-9620

www.pega.com

Document: Software Version: 6.3.3 Updated: December, 2013

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

Predefined Access Roles and Privileges ............................................................. 11

Predefined Organizations, Divisions, and Units .................................................. 12

Default Service Level Rules ............................................................................. 12

Correspondence Templates ............................................................................. 18

Smart Dispute Reports ................................................................................... 23

Chapter 3: ......Understanding Smart Dispute Business Processing ................. 28

The Main Flow of Work in Smart Dispute .......................................................... 28

Qualifying the Dispute using the TalkOff Flow .................................................... 32

Choosing a Reason Code using the ProcessDispute Flow ..................................... 35

Modifying the Provisional Credit Decision Tree ................................................... 37

Setting Up Automatic Write-Off Criteria ............................................................ 38

Debit Transaction Dispute Processing ............................................................... 43

Reg E Processing ........................................................................................... 45

Multi-Dispute Claim Processing ........................................................................ 48

Chapter 4: ......Extending Your Framework Structure Using DCO Tools ........... 52

What is Direct Capture of Objectives (DCO)? ..................................................... 52

Using the DCO Tools ...................................................................................... 53

Accessing DCO Tools ...................................................................................... 53

Next Steps ................................................................................................... 59

1


Chapter 5: ......Personalizing Smart Dispute .................................................... 66

Setting Up Correspondence Verification ............................................................ 66

Modifying Automatic Correspondence Generation .............................................. 67

Inserting Cardholder Supporting Documentation Requests .................................. 72

Modifying the OnUs Decision Map .................................................................... 74

Modifying Dispute Qualification Scripts ............................................................. 74

Setting Up Duplicate Scoring Rules .................................................................. 76

Modifying SnapStart for Smart Dispute ............................................................ 78

Using Dispute Types to Determine Work Objects ............................................... 80

Defining and Processing New Reason Codes ...................................................... 84

Defining New Reason Code Advisor Categories .................................................. 89

Defining New Bank Identification Numbers (BINs) ............................................. 90

Chapter 6: ......Working With the Accounting Functions .................................. 92

Setting Up Account Types ............................................................................... 92

Setting Up Accounting Party Data .................................................................... 94

Defining the Chart of Accounts ........................................................................ 97

Setting up Payment Types .............................................................................. 98

Accounting Step Rules.................................................................................... 99

Setting up Verification Levels .........................................................................105

Cutoff Times ................................................................................................106

New Suspense Accounting .............................................................................108

Cut-off Times and the Calendar ......................................................................110

Adjusting Automatic Chargeback ....................................................................111

Understanding How Multi-currency Works ........................................................113

Chapter 7: ......Integrating Smart Dispute ..................................................... 122

Creating Integration Activities ........................................................................122

Generating a Data Dictionary .........................................................................123

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. Rule-based 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,

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 application-specific functions (such as contact management or customer service). The rules you modify when extending the Framework are at the top level, as they supersede the Framework defaults.

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


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.

https://pdn.pega.com/pega-academy/about�

https://pdn.pega.com/�

https://mesh.pega.com/community/projects/financialservicesframeworkenablement/smartdisputeenablement�

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


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.

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


Corp-

Enterprise Reuse layer

FW-

Data-

Int-

Corp-Div-

Division Reuse layer

Data-

Int-

Corp-App-Disputes

Implementation Layer

Data-

Int-

Work-

Dispute

Corp-FW-DisputesFW-

Framework Layer

Data-

Int-

Work-

Dispute

Sample Enterprise Class Structure Extending Smart Disputes

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

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 Access Group DisputeEntry DisputeEntry User


Operator Access Group DisputeFraudProcessing DisputeFraudProcessingUser DisputeManager DisputeManagerUser DisputeProcessing DisputeProcessingUser DisputeSimple DisputeSimpleEntryUser DisputeSupervisor DisputeSupervisorUser DisputeSysAdmin 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

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

Privileges

Disp

ute

Entry

Fraud

Man

ager

Disp

ute

Processing

Clerical

Su

pervisor

SysA

dm

in

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


Privileges

Disp

ute

Entry

Fraud

Man

ager

Disp

ute

Processing

Clerical

Su

pervisor

SysA

dm

in

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

Predefined Organizations, Divisions, and Units Smart Dispute comes with the following predefined organization, division, and units.

Organization: Pega.com Division: Administration

Units: 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 $500.00. 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,

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 Action Fulfillment Assignment 30 44

ACTIONMEDIATIONRULING Action Mediation Ruling Assignment 3 7

ACTIONMEDIATIONRULING 3 7

ACTIONMEDIATIONRULINGNF 8 10

ACTIONNONFULFILLMENT Action Non Fulfillment Assignment 1 2

ANSWERQUESTIONS Answer Questions for Assignment 5 10

ARBCBINITIATION 30 45

ARBITRATION Arbitration Assignment 1 1

ARBITRATIONWB Arbitration Workbasket Assignment 25 30

ARBITRATIONWBINTL Arbitration Workbasket for International Assignment 30 45

ASSIGNFORAGEDWRITEOFF Assign For Aged WriteOff Assignment (called via MapValue!)

180 210 FinResumeAgedWriteOff2

ASSOCIATIONSLA AssociationSLA 0 OverrideOverallSLA 0 ActionTransferToWorkBasket

CHARGEBACKREVERSALASSIGN Chargeback Reversal Assign Assignment 1 1

CHECKFORRESPONSE30 Check 30 days for response - Pending Fulfillment

30 31 AdvanceFlow

COMPLIANCE Compliance Assignment 1 1



COMPLIANCEWB Compliance 30 30

COMPLIANCEWBINT 75 90

DECISIONINBOUNDARBITRATION SLA for Decision Inbound Arbitration Assignments 20 30

DISPUTEMAINFLOW SLA passed into OverAll SLA Flow to run on Disputes

30 UrgencyUpdateAssignments 60 UrgencyUpdateAssign

ments

FINAGEDWRITEOFF 90 90

FINSTEPCUTOFF 5 hours 10 hours

FINWRITEOFFAFTER30 Wait 30 days before Aged Write Off 30 FinResumeAgedWrite

Off2 30 FinResumeAgedWriteOff2

FINWRITEOFFAFTER30 30 30



GOODFAITHOUTBOUND Good faith wait for 30 days 30 ResumeGoodfaith 30 ResumeGoodfaith

GOODFAITHWB Good Faith Workbasket Assignment 25 30

GOODFAITHWBOUTBOUND Good Faith Workbasket (Outbound) Assignment 25 30 ResumeGoodfaith

HASDUPLICATES Has Duplicate Assignment 1 1

INBOUNDARBITRATION Inbound Arbitration Assignment 25 30

INBOUNDCOMPLIANCE Inbound Compliance Assignment 20 30

INBOUNDPREARBITRATION Inbound PreArbitration Assignment 20 30

INITIATEPREARBITRATION Initiate PreArbitration Assignment 1 1

INVOKEINSERTDISPUTEDETAILS Invoke Insert Dispute Details Assignment 0 0

MEDIATION7 Service level Mediation7 7 7

15



NONFULFILLMENTASSIGNMENT Non Fulfillment Assignment Assignment 1 3

OPERATOR SLA for Operator Assignment 1 1

PAYABLEWRITEOFFSLA Wait 180 days before Aged Write Off (Payable) 150 180 ResumeAgedWriteOff

2

PENDCHARGEBACK Pending Chargeback 0 ResumeIfCredited 0 ResumeCreditedOrNot

PENDFORFULLFILLMENT Pending For Fulfillment Assignment 30 31 AdvanceFlow

PENDINGCARDHOLDERRESPONSE 2 minutes 5 minutes

PENDINGFEECOLLECTION Pending Fee Collection SLA 10 12

PENDINGFUNDSDISBURSEMENT 10 12

PREARBITRATION Prearbitration wait for 30 days 0 ResumePreArbitration 0 ResumePreArbitration

PREARBITRATIONOUTBOUND 30 30

PREARBITRATIONWB SLA for Prearbitration Workbasket Assignment 25 30

PRECOMPLIANCEOUTBOUND Good faith wait for 30 days 30 ResumePreCompliance 30 ResumePreComplianc

e

PRECOMPLIANCEWB Precompliance Workbasket Assignment 25 30

PRECOMPLIANCEWBOUTBOUND Precompliance Workbasket (Outbound) Assignment

25 30 ResumePreCompliance

PROCESSCHARGEBACK Process Chargeback Assignment 1 2

PROCESSDISPUTE Process Dispute Assignment 5 10

PROCESSDUPLICATEREQUESTS Process Duplicate Requests Assignment 1 1



PROCESSONUSDISPUTES Process OnUs Disputes Assignment 2 5

PROCESSSECONDCHARGEBACK 45 60

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)

150 180

REGZCREDIT Regulation Z SLA 1 2 ResumePreArbitration

REPRESENTMENT Prearbitration wait for 30 days 0 ResumePreArbitration 0

REPRESENTMENTASSIGNMENT Representment Assignment 30 45 ResumeFlow

REPRESENTMENTDOCASSIGNMENT

Wait For Docs Assignment in Representment Flow 21 22

RESOLVECHARGEBACK Resolve Chargeback Assignment 30 31

SENDEDITACKNOWLEDGELETTER Send Edit Acknowledge Letter Assignment 1 2

SENDEDITCARDHOLDERLETTER Send Edit Cardholder Letter Assignment 1 2

SENDEDITCOVERLETTER Send Edit Cover Letter Assignment 1 2

SENDEDITGOODFAITHLETTER Send Edit Good Faith Letter Assignment 1 2

SENDEDITMCCOVERLETTER 1 2

SENDEDITPREARBITRATIONLETTER

Send Edit PreArbitration Letter Assignment 1 2

SENDEDITPRECOMPLIANCE Send Edit Precompliance Assignment 1 2 UrgencyUpdateAssign

ments

17



STANDARD 30 60

TALKOFFPROCESS Talk Off Process Assignment 0 0

UNTIMELY Untimely Assignment 1 2

WAITFORDOCUMENT Wait For Document Assignment 10 20

WRITEOFFAFTER0005 5 minutes 5 minutes

ConfirmReversePCFromClaim Complete Investigation service level 1 sec ProcessReverseClaim

LevelPCAcctg

ReverseProvisionalCreditFromClaim

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 Wait for RegEPCDate service level

WaitForSignedAffidavit 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 Process Provisional Credit final service level . ProcessFinalCredit

EscalateCompleteInvestigation Escalate Complete Investigation . EscalateToSupervisor

Figure 3-8. Default Service Level Rules


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 service-level 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

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



PegaCard-Sd-Debit ReminderToReturnWSUD Mail

PegaCard-Sd-Debit EscalateToSupervisor Email

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 Email

PegaCard-Sd-Dispute- CardHolderAffidavit Mail

PegaCard-Sd-Dispute- Footer Email

PegaCard-Sd-Dispute- GeneralCoverLetter Mail

PegaCard-Sd-Dispute- GeneralHeader Mail

PegaCard-Sd-Dispute- GoodFaithLetter Mail

PegaCard-Sd-Dispute- Header Email

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

21



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

Exhibit2E_2 Mail

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- 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 e-mail, 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, e-mails, and faxes that are sent to customers and banks.

23


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


Accounting Reports

End of Day Balancing

Report Name Graph All account types – today All account types – specified dates Payable and receivable only – today Payable and receivable only – specified dates

Suspense Reports

Report Name Graph Outstanding – summary Outstanding – age Outstanding – amount range Resolved – today Resolved – past 7 days Resolved – past 30 days Resolved – specified dates

Write-Off Reports

Report Name Graph Today Specified Dates

Quality Reports

Resolution Quality Reports

Report Name Graph 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

History Analysis Reports

Report Name Work history count

Monitor Process Assignment Reports

25


Summary Reports

Report Name Graph 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

List Reports

Report Name Graph Assignments for workbasket Work by operator Work for work basket

Monitor Processes Reports

Summary Reports

Report Name Graph 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

List Reports

Report Name Graph Entered by me Work by resolved operator


Analyze Process Quality Reports

Summary Reports

Report Name Graph 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

Analyze Process Performance Reports

Summary Reports

Report Name Graph Task duration √ Timeliness by task √ Task performance √ Action analysis Action processing time √ Performance detail Action performance Action processing time in hours

Regulation E Reports

Summary Reports

Report Name Graph 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 √

27


Report Name Graph Reg E Audit Report, Open Items Reg E Audit Report, Resolved Items


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:

29


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

Representment PreArbitration ArbitrationChargebackTicket Retrieval (optional)


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 4532. For step-by-step information about the TalkOff flow, see “Qualifying the Dispute using the TalkOff Flow” on page 4532.

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.

31


DisputeMainFlow Flow Diagram

The DisputeMainFlow diagram shows the backbone of Smart Dispute processing for credit card disputes.


Figure 4-11. 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.

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 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 4-12. Flow Diagram for PegaCard-Sd-Dispute-TalkOff

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.


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 4-13. Flow diagram for PegaCard-Sd-Dispute-ProcessDispute

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 6-14. 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 top-level class name), select your RuleSet from the selection box, and then click Save As.

7. Edit the If statements as needed.


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

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

Modify the values for cardholder value, account details, dispute amount, fraud indicator, and result count.

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.


3. Select Declare- > DecisionTree. A list of rules appears.

39


4. Click IsWriteOff. A Decision Tree form appears (Figure 6-15).

Figure 6-15. Modifying the Write-Off Decision Tree



7. Edit the If statements as necessary.


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

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

Modify the values for cardholder value, account details, dispute amount, fraud indicator, and result count.

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.


3. Selet Obj- > MapValue. A list of rules appears.

4. Click WriteOffOnLower. A Decision Tree form appears (Figure 6-16).

Figure 6-16. Modifying a Write-Off Threshold



7. Enter a new write-off threshold.

8. Click Save.

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:



3. Select Obj- > ServiceLevel. A list of rules appears.

4. Click ReceivableWriteOffSLA. A Service Level form appears (Figure 6-17).

Figure 6-17. 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.


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:



3. Select Obj- > MapValue. A list of rules appears.

4. Click PayableWriteOffSLA or ReceivableWriteOffSLA. A Map Value form appears (Figure 6-18).

Figure 6-18. 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.

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.


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.

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.


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

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


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 5th business day, the reversal accounting entry is completed with the completion notice sent to the customer.

Multi-Dispute Claim Processing Multiple dispute claims can occur for a number of reasons but are most prevalent with fraud. For example, a customer notices several 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

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


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

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.


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.

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

Accessing DCO Tools

Run the Application Accelerator

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: DisputeSysAdmin

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


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.

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

1. 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 = 06.03.01

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


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.

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.


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.

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:


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

Sample App

MyCoCardSdVisaAP:04-02

MyCoCardSdVisaCEMEA:04-02

MyCoCardSdVisaInterlink:04-02

MyCoCardSdVisaCEMEA:04-02


MyCoCardSdVisa:04-02


MyCoCardSdVisaLAC:04-02

MyCoCardSdAdvisor:04-02

MyCoCardSdVisaLAC:04-02

MyCoCardSdVisaEurope:04-02

MyCoCardSd:04-04

MyCoCardSdVisaEurope:04-02




MyCoCardSdMasterCard:04-01

MyCoCardSd:04-04

MyCoCardSdAMEX:04-01


MyCoCardSd:04-04

SD Framew

ork

PegaCardSdAdvisorVisaAP:04-02

PegaCardSdAdvisorVisaAP:04-02

PegaCardSdAdvisorVisaInterlink:04-02

PegaCardSdAdvisorVisaCEMEA:04-02

PegaCardSdAdvisorVisaCEMEA:04-02

PegaCardSdAdvisorVisaCanada:04-03



PegaCardSdAdvisorVisaUS:04-02

PegaCardSdAdvisorVisaLAC:04-02

PegaCardSdAdvisorVisaLAC:04-02

PegaCardSdVisaUS:04-04-40

PegaCardSdAdvisorVisaEurope:04-02

PegaCardSdAdvisorVisaEurope:04-02

PegaCardSdVisaInterlink:04-04-40



PegaCardSdVisaCanada:04-04-40



PegaCardSdVisa:04-04-67

61


All Associations, All Regions

Visa All Regions

Visa US and Canada

PegaCardSdVisaAP:04-04-40

PegaCardSdVisaAP:04-04-40

PegaCardSdAdvisorVisa:04-03



PegaCardSdConfig:04-03

PegaCardSdVisaCEMEA:04-04-40

PegaCardSdVisaCEMEA:04-04-40

PegaCardSdAdvisor:04-03



PegaCardSdIssuer:04-01

PegaCardSdVisaLAC:04-04-40

PegaCardSdVisaLAC:04-04-40

PegaCardSdVisaEurope:04-04-43

PegaCardSdVisaEurope:04-04-43







PegaCardSdMasterCard:04-04-67


PegaCardSdAdvisorMasterCard:04-04


PegaCardSdAMEX:04-04


PegaCardSdAdvisorAMEX:04-02




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


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!435237 Model for creating a new party

Data Transform PEGACARD-PARTY-BANK!BIN345237 Model for creating a new party for issuer 345237









63







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



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

MYCOCARDSD-WORK-DISPUTE!CHARGEBACKSBYREASONCODE Display Report for Chargebacks by Reason code

Report Definition

MYCOCARDSD-WORK-DISPUTE!DISPUTESAPPROACHINGTIMEFRAMES (Change RD Category to ChargeBacks) 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

65



Report Definition

MYCOCARDSD-WORK-DISPUTE!REPRESENTMENTSBYREASONCODE Display Report for representments by Reason code

Report Definition

MYCOCARDSD-WORK-DISPUTE!WRITEOFFSBYREASONCODE 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.


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

67


Figure 5-19. 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.


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

69


Figure 5-20. The New Work Flow


5. Select your RuleSet name from the selection box and click Save As.


6. Double-click the flow image to open the flow in Visio (Figure 5-3).

Figure 5-21. 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).

71


Figure 5-22. SLAOpenCoveredProcessing Activity



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:


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 5-23. SLAOpenCoveredProcessing Activity




7. Click the red arrow next to the step you want to modify. The detail information for that step appears (Figure 5-6).

Figure 5-24. 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.


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:

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:


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 5-25. Sample Document Type



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.



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:


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-Dispute- class. A Map Value form appears (Figure 5-8).

Figure 5-26. OnUs Map Values


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


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

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:


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 5-27. TalkOff Flow Definition


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


Figure 5-28. Harness Section for ActionInvokeTalkOff

9. Click the HTML tab and edit the text as necessary.


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.

77


To change a scoring rule:


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 5-29. Modifying a Scoring Rule


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


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

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


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.

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


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 5-30. SnapStart Activity — Parameters Screen

8. Edit the parameters as necessary and then click Save.


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.

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 5-31. VisaDisputeDT Decision Tree


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.


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


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:


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.

83


Figure 5-32. AssociationDescMatrix Map Value


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.


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.


Figure 5-33. The VisaDisputeDT Decision Tree


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


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:

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:


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 5-34. Reason Code Form

6. Complete the fields of the tabs as described in Figure 5-17.


Field Description Short Description

Required. Description of the reason code.


Field Description Timeframes Tab

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

Primary Timeframe

Number of days within which the dispute is still valid. This date should be checked by a CheckTimeliness activity.

Primary Applies To

Property to which to apply the primary timeframe.

Primary Condition

When rule defined on the same class as the Reason Code.

Secondary Timeframe

Number of days within which the initiated dispute is still valid. This date should be checked by a CheckTimeliness activity.

Secondary Applies To

Property to which to apply the secondary timeframe.

Secondary Condition

When rule defined on the same class as the Reason Code.

Documents Tab

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.

Inbound Documents Label

Simple label for the inbound document.

Inbound Documents Property

Property that signifies that this inbound document is attached to the case.

Inbound Documents Required?

When rule that determines if the inbound document is really necessary.

Inbound Documents Type

Type of inbound document (instance of Rule-PegaCard-ReasonCode-DocType).

Inbound Documents Criteria

List of criteria displayed to the user when attaching the inbound document to the case. The document should contain the information in the criteria.

Outbound Documents Label

Simple label for the outbound document.

87


Field Description Outbound Documents Property

Property that signifies that this outbound document is attached to the case.

Outbound Documents Required?

When rule that determines if the outbound document is really necessary.

Outbound Documents Type

Type of outbound document (instance of Rule-PegaCard-ReasonCode-DocType).

Outbound Documents Criteria

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.

Document Indicator

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 Contains a list of ancillary questions. This is a list of keys to instances of Rule-PegaCard-ReasonCode-Question.

Ancillary Questions

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.

Message Text Key to an instance of Rule-Obj-HTML or Rule-HTML-Fragment defined on the class the reason code is defined on or

Default case to fraud?

Select if this is a fraud-related reason code.

Next Tab Lists those things that may need to be done after the ancillary questions are answered.

Retrieval Required?

Enter “true,” “false,” or a When rule that controls whether or not a retrieval request is required.

Retrieval Flow Flow rule to be run for the retrieval request. Chargeback Flow

Flow rule that contains the chargeback processing.

Second First Chargeback?

Select if this reason code allows second first chargebacks.


Field Description Chargeback Amount Limitation

Activity that calculates acceptable amount for a chargeback.

Limits Tab Limits the reason code. ReasonCode Limitations

To add a limitation, click the Append Row button.

History Tab Enter a detailed description of the reason code and information on how it is used. To review the Save history, click History Details.

Figure 5-35. Fields on the Reason Code Form

To create a new ancillary question:



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 5-36. Ancillary Question Form

6. Complete the fields of the tabs as described in Figure 5-19.


Field Description Details Tab Lists the Display HTML, Category, and Validation

rules. Display HTML Rule containing text of the question that is

displayed to the user for customer query. Category Type of question or grouping to which a

question is related.

89


Field Description Validation Rule

Sets the requirements for the question, the 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 5-37. 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:


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.


Figure 5-38. HTML Property Form for Category


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.


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:



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.

91


Figure 5-39. Model Form


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.



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 top-level 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

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:


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 6-40. 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 6-41. 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.



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 6-42. 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).

95


Figure 6-43. Rule Count and Modification Summary by Class, RuleSet

6. Click the RuleSet: MyCoCardSd link. A list of class rules appears.

Figure 6-44. 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 6-45. 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.


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

97


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


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 6-47. Map Value Window


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.


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.


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:


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

99


Figure 6-48. Modifying a Payment Type


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.


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


− 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 6-49. 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 6-50. Transaction Tab of Adjustment Rule Window (Left and Right Sides)

101


Fields on the Adjustment Rule Form

Figure 6-12 describes the fields in the Adjustment Rule form.

Field Description Short Description

Required. Short description of the rule. This value is displayed during manual accounting in the list of step rules the user can select.

Step Tab Class of the Step

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

Activity for Verification Flow

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.

Model to create Step

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

Validate Activity

Reserved for future use.

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

Transactions Tab


Field Description Group 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.

Note that Smart Dispute does not use groups because there is a singe internal account for Receivable, Write-Off, etc.

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

DR / CR 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.

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

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

Pymt Type Name of Rule-PegaApp-Financial-PaymentType rule to use for this transaction. The payment type rule associates correspondence with the transaction.

103


Field Description Default Account From

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

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.

Account From Value

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

Protect Account?

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.

Default Amount From

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.


Field Description Amount From Value

Specifies a property reference if DefaultAmountFrom is Property. A reference can be any fully qualified property reference from any page. If the property reference is not dot qualified, then Smart Dispute assumes the property is on the top level of the work object page.

Specifies an actual amount number value if Default Amount From is Literal. Do not use quotation marks, $, or commas (that is, specify 1000.00 and not $1,000,00 or $1000.00 or “1000.00”).

Protect Amount?

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.

Security Tab

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

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

When Name

Optional. Enter a Rule-Obj-When rule that equal true for 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.

History Tab

Full description of the adjustment rule and information on its usage.

Figure 6-51. Fields in the Adjustment Rule Window

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

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.


To change amounts or verification levels



3. Select Obj- > MapValue. A list of rules appears.

4. Click FinVerificationFlowByAmount. The FinVerificationFlowByAmount Map Value screen appears(Figure 6-13).

Figure 6-52. Modifying Verification Levels


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-

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 6-53. Past-Goal and Past-Cutoff Warnings in the User Interface

To change the default cutoff rule:



3. Select PegaApp- > Financial- > Cutoff. A list of rules appears.

4. Click the Default instance. The Cutoff Rule form appears (Figure 6-20).


Figure 6-54. Modifying the Cutoff Rule


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.


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 150/USD DR Fee Reversal 35/USD CR Customer Account 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

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 150/USD DR Fee Reversal 35/USD CR Customer Account 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


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 non-business day.

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 1996–2006 are included; Figure 6-21 shows the 2006 calendar.

Figure 6-55. 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:



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 6-56. Activity to Determine Automation



8. Click the Expand Method icon to see the method information (Figure 6-23).

Figure 6-57. 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.


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


Property Clipboard Page Source DisputeAmount pyWorkPage (pyWP) PostedAmount PostedAmount pyWP.AccountTransaction Table:Pcd_Transactions PostedCurrency pyWP.AccountTransaction Table:Pcd_Transactions PostedCurrencyDesc pyWP.AccountTransaction Mapped Value SettlementAmount pyWP.AccountTransaction Table:Pcd_Transactions SettlementCurrency pyWP.AccountTransaction Table:Pcd_Transactions SettlementCurrency Desc

pyWP.AccountTransaction Map Value

TransactionAmount pyWP.AccountTransaction P Table:Pcd_Transactions TransactionCurrency pyWP.AccountTransaction Table:Pcd_Transactions TransactionCurrencyDesc

pyWP.AccountTransaction Mapped Value

AuthorizationAmount pyWP.AccountTransaction Table:Pcd_Transactions AuthorizationCurrencyCode

pyWP.AccountTransaction Table:Pcd_Transactions

AuthorizationCurrency Desc

pyWP.AccountTransaction Mapped Value

BasicCurrencyConRate pyWorkPage Table:Pcd_Transactions BaseAmount pyWorkPage Table:Pcd_Transactions BaseCurrency pyWorkPage Table:Pcd_Transactions BillingCurrency pyWorkPage Posted Currency BillingCurrencyByBIN pyWorkPage Mapped Value BillingCurrencyDesc pyWorkPage PostedCurrencyDesc DefaultCurrency pyWorkPage Table:Pcd_Transactions CommonCurrencyConRate

pyWorkPage BasicCurrencyConRate

Figure 6-59. 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.

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 6-60. 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 6-61. 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.


Figure 6-62. Transaction Amount Property – Qualifier Setting

Figure 6-29 shows the Map value currencies used by the Smart Dispute

Figure 6-63. 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 0.500.

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.

117


Figure 6-30 shows the original Dispute Amount of 163.20 USD, the conversion rate, and the disputed transaction amount in GBP.

Figure 6-64. Case Details

Figure 6-31 shows the updated dispute amounts.

Figure 6-65. Updated Dispute Details

Figure 6-32 shows how Smart Dispute passes the change through to process the chargeback.


Figure 6-66. 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).

119


Figure 6-67. 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


Note: For this procedure, we are going to use the name SampleAmount as the property name.

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.


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 Integration Activity PegaApp-Interface-Account

AppGetAccountInfoRefresh

PegaApp-Interface-BusinessUnit

AppGetAdditonalBusinessDetails


AppGetAdditonalBusinessFaxDetails


AppGetAdditonalBusinessPhoneDetails

PegaApp-Interface-Contact

AppGetNotesForContact

Figure 7-68. Activity Integration Data

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


2. Click the Customize Summary Criteria link, which is below the report heading. The Customize Criteria page appears (Figure 7-6).

Figure 7-70. 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 7-71. Rule-Obj-Property Report

7. Optionally, click the Export to Excel button to export the class data to an Excel spreadsheet.

Smart Investigate For IssuerSmart Dispute Overview Smart Dispute is a comprehensive rules-based...

Documents

Transcript of Smart Investigate For IssuerSmart Dispute Overview Smart Dispute is a comprehensive rules-based...