Difficulty: beginner
Estimated Time: 40 minutes

The Business Background

It is your first day working at Pecunia Corp. One of the divisions of the company is the Issuer, and one of the most common, yet expensive, tasks is the dispute of a credit card transaction. In this scenario we will look at the installation process of Red Hat Process Automation Manager (RHPAM) 7 on OpenShift Container Platform, as well as some of the tasks that a production installation will require. Note: Because of the limitations of the workshop environment, all of the topics regarding persistence will be omitted.

One of the processes that the bank has identified as a candidate for automation is the credit card dispute process. The processing cost of this business process is very high, regardless of the amount that is being disputed. Second, it is also a heavily regulated process that requires:

  • Audit trails
  • Mandatory steps to be taken

In this workshop we will automate this process to:

  • reduce the processing cost.
  • improve customer satisfaction by reducing turnaround time through automation.
  • make decisions reproducable by automating business rules.
  • provide insight into the process, enabling the use of analytics to analyse and optimize the dispute process.

This scenario has explained how to create and configure your environment to author business automation assets, in the next scenarios you will learn how to build those assets based on the Functional Requirements defined.

Introduction and Installation Scenario

Step 1 of 6

Use Case Introduction

Use Case Overview

The requirements that are handed to you: These requirements are the policies of Pecunia Corp. to solve a Credit Card Dispute.

Background

The cost of processing a credit card dispute is very high, and also critical from the customer experience perspective.

Usually the credit card holder is stressed to protect the assets trusted to the bank, therefore one of the requirements for the interaction with the dispute system is the constant feedback to the customer, informing the latest status of the dispute. E.g., who is currently processing the dispute, is additional information from the customer required, has the dispute been automatically accepted, has something gone wrong with the dispute, etc.

Most of the complexity with the CC Dispute process comes from the fact that is a multi-step process where every dispute is a one-off situation, the actual outcome of the dispute is a result of the interactions between the different actors and the decision logic. On top of that, the information regarding the case, has to be the input and output of every interaction, everybody need to look at the same data and be observers of changes in it.

The actors that we can identify are:

  • Credit Card Holder: aka Customer
  • Credit Card Issuer: In this case Pecunia corp.
  • Card processing network: The organization that oversees the process. Some differ in their procedures than others.
  • Credit Card Acquirer: A financial institution that obtains the rights to the merchant’s account and tasked with getting payment on the merchant’s behalf.
  • Merchant: Seller of the goods and must either fight or accept the chargeback.

We can resume the process in the following diagram:

The basic steps are:

1- The Credit Card Holder starts a dispute with the CC Issuer.

2- The CC Issuer needs to decide what type of processing is required for the dispute (automated chargeack or normal processing).Jump to step 3.1. or 3.2.

3.1- The CC Issuer process the automated chargeback. Jump to step 5.1.

3.2 - The CC Issuer needs to do standard processing, contact the Card Processing network to start the dispute, the Credit Processing Network then contacts the CC Acquirer that requests evidence to the merchant and a formal response to the dispute.

3.3 - The Merchant send the evidence and response to the CC Issuer

4- The CC Issuer assess the risk of the dispute.

4.1- The CC Issuer requests a manual approval for the dispute from a knowledge worker. Jump to step 5.1. or 5.2

4.2- The CC Issuer based on the data resolves the case. Jump to step 5.1. or 5.2

5.1- The dispute is accepted and the money reimbursed to the CC Holder and the backoffice chargeback for fee transactions started

5.2- The dispute is rejected

6- The CC Issuer informs the CC Holder of the result.


Business Requirements:

There are two points in the process where depending on a business decision, the processing path bifurcates. The decision making is right now subjective, as a human - in this case a CC Issuer agent- is responsible to reach a conclusion based on his/her individual knowledge.

Hence there are two decision's sets that change the overall processing making: One set that determines whether the dispute can be qualified for automated chargeback, and a set that determines the risk of the dispute for manual approval and resolution.

For the first scenario, going back and forth in the whole processing chain is costly for all the parties involved, plus the amount of the dispute can be less than the cost of processing the dispute, in addition to that the CC Issuer can offer automated chargeback to it's highly loyal customers.

So the first bifurcation point gives Pecunia corp the ability to gain loyalty with strategic customers and avoid cost, this scenario is Automatic vs Standard Processing. The following diagram describes the scenario:

The second use case has the decisions to determine the risk of the transaction and if a manual approval is required.

Once that is decided that the dispute will be processed in a standard way, by contacting all the chain of CC transaction processing (3) we have the next bifurcation in step 4 of the processing, based on the case information we need too determine if a dispute needs a manual approval, to such effect we have the following rule:

Every amount larger than 1000 should be manually approved.

An also at this point we need to determine the risk profile of the dispute, this risk scoring will be part of the input for both the manual approval path and the automated resolution.

The risk of the transaction is determined by the status of customer and the amount of the dispute:

  • For a standard customer, and a dispute amount between 0 and 100, the risk is low.
  • For a standard customer, and a dispute amount between 100 and 500, the risk is medium
  • For a standard customer, and a dispute amount above 500, the risk is high.
  • For a silver customer, and a dispute amount below 250, the risk is low.
  • For a silver customer, and a dispute amount between 250 and 500, the risk is medium.
  • For a silver customer, and a dispute amount above 500, the risk is high.
  • For a gold customer, and a dispute amount below 500, the risk is low.
  • For a gold customer, and a dispute amount over 500, the risk is medium.

Functional Solution:

Have business rules that will take into account consistent criteria defined to assess risk and automate processing. The business user must have the ability to change these criteria anytime if needed, and apply the changes according to the release process of Pecunia corp..


Non Functional:

Allow the user to change the criteria without technical assistance. Have the tooling for the user to update the rules but using standard spreadsheet-like decision tables or cuasi natural language.

Terminal
Openshift Console
Business Central