Payment inquiries are among the most common and time-consuming problems for commercial banking client firms to solve. The most common scenarios are a late payment or a payment received is missing information that prevents processing by the bank or the customer. Most banks have back-office investigation tools (such as Pega Smart Investigate™ for Payments) that are highly specialized to support payment investigations. These tools integrate with SWIFT messaging services, which securely allow banks that have touched a transaction to communicate securely across the globe. These tools, however, lack robust front-office customer interaction management across channels. The Payment Inquiry Microjourney fills this gap by letting Treasurers or Chief Financial Officers (CFOs) initiate payment investigations through a self-service website and monitor progress of the investigation. 

This article includes the following topics about the Payment Inquiry Microjourney.

• Business Value
• Required applications
• Personas, channels and usage
• Example usage
• Stages and steps
• Data model
• Enabling the Microjourney
• FAQs

Business value

Payment Inquiry provides value by making it easier for commercial bank customers to initiate payment investigations through multiple channels including web self-service and web chatbot. It also simplifies communication between back-office and front-office resources working on the case at the bank.  For firms that extend the out-of-the-box case to support integration with the back-office investigation tool  , additional efficiency is gained by removing manual updates in multiple systems. Either way, this microjourney   reduces calls from customers because it provides them with a clear explanation of the process and status of the inquiry.   

Required applications

You use the following required and optional applications for this microjourney.

• Required – Pega Customer Service™ for Financial Services 8.4
• Optional – Pega Sales Automation™ or other sales automation application to receive alerts
• Optional – Pega Smart Investigate™ for Payments or other payment investigations  application to receive the Payment Inquiry case.  
   

Personas, channels and usage

Example usage

In the simplest configuration, the case flow follows this sequence:

• The Treasurer launches the Payment Inquiry case from a Quick Links section of web self-service, selects the transaction and reason for the inquiry, and submits as shown in the series of screenshots below. 

• After the case is submitted, the Customer Service Officer’s Pulse feed shows that one of their customers (tagged as a favorite) has opened a Payment Inquiry case as shown in the screenshot below. 

• Simultaneously, the Payment Inquiry case appears in the Back Office Payment Inquiry queue (see screenshot below).   

• In order to process this Payment Inquiry case, a Payment Investigator (or a back-office worker) launches an investigation case in the payments investigation tool of the bank and updates the Payment Inquiry case as shown in screenshot below.

• The Treasurer can see the changes in status as shown in the screenshot below on the bank’s self-service portal.   

In a full-blown implementation (in which all extension points are configured), the flow above can also include: 

• An alert feature, as illustrated in the following screenshot of a self-service portal, notifies the Treasurer that a transaction requires their review.  The Treasurer could then proceed to get more details and also initiate the inquiry.

• The investigation case is automatically created in the integrated back-office payments investigation tool (such as Pega Smart Investigate™). Updates and resolution are reflected in the Customer Service application accordingly. In the following example screenshot, where Pega Smart Investigate™ for Payments is integrated, the Customer Service Officer can see updates in Customer Service as well as drill down into additional details about the investigation case.

• Proactive notification to other stakeholders, such as an account manager can also be configured.  The following screenshot illustrates the notification on a Pega Sales Automation™ for Financial Services portal.

Stages and steps

There are three stages of the case flow as shown in the screenshot below:
1.    Collect inquiry details is about identifying the transaction and the type of problem that is associated with it.
2.    Process investigation is about notifying stakeholders and opening an investigation case in the investigation tool.
3.    Resolution.
 

Data model

The Data model tab of the Payment Inquiry case type (in the screenshot below) displays the data objects that are used.

Enabling the Microjourney

Payment inquiry can be implemented nearly out of the box.  The only extension point (#1 below) that must be implemented is Fetch transaction , which provides the list of possible transactions that could be the subject of inquiry as well as the transaction details. Other extensions to improve notification, customize inquiry types and related process steps and SLAs, and integration to a back-office investigation tool are explained in the FAQ section.  

 To get list of transactions or to get details for a specific transaction from an appropriate source, extend the Activity GetTransactionsByAccount, which is provided as an extension point.

FAQs

What are the common extensions?

This section lists and describes extension points in this microjourney that can enhance the user experience, add additional integrations and automation in your implementations.

1. To display transaction alerts on the Self-Service portal, extend the GetTransactionAlerts activity, which is provided as an extension point, to source the alerts from an external transaction system.

2. Reason for Inquiry - by default, the following types of inquiry are displayed. If you want to add more to this list, add additional field values to the InquiryReason property.
   1. Beneficiary claims non-receipt
   2. Payment amendment
   3. Payment recall
   4. Payment status
   5. Return of funds
   6. Unable to apply funds
3. Build a logic to identify the probable reason for the inquiry:
   1. The ReasonForInquiry decision tree has a simple logic to determine the probable inquiry type based on transaction details. This decision tree  is built as a combination of multiple when rules for each type of inquiry.
   2. To add other types of inquiry, you can extend the ReasonForInquiry decision tree. 

3. You can also update any of the when rules applicable for specific inquiry types to add your custom logic to suggest the inquiry type. For example, the ConditionForUnabletoapplyfunds when rule needs to be modified if you want to change the logic to suggest that the inquiry could be of type Unable To Apply.

4.  In the same ReasonForInquiry decision tree, for each inquiry type, set the values of the Due Date and Due Data Expiry properties by clicking the Take Actions button against each condition.

5.  Extend the SetDisplayTextForInquiry data transform to fetch or update user-friendly text, depending on the probable reason for the inquiry.

4.  Extend the NotifyStakeholders flow to customize the process to notify necessary stakeholders within the bank and send correspondence to customers with updates on the case.

5. By default, the Payment Inquiry case works with the assumption that the back-office payments investigator receives the payment inquiry requests in Pega Customer Service™ for Financial Services and manually initiates the investigation in the back-office payments investigation tool. To integrate the back-end payments investigation tool, follow the steps below.
   1. In the InvestigationSystemSettings data transform, set the value of IsInvestigationSystemSet to true.

2. To create an external investigation case:
   1. Build a connector to launch an investigation in the payments investigation tool.
   2. Extend the CreateInvestigation flow rule and invoke the connector.

3. Make sure you capture the reference of the payments investigation case in the PaymentsInvestigationID property of the Payment Inquiry case. 

3. Extend the ResolveInvestigationCase flow rule to customize the process for resolving the Payment Inquiry case when the case in the payments investigation tool is resolved.

4. By default, the reference to the case created in a payments investigation tool is captured. If you want to display additional details of the case, customize the ConfirmCaseDetailsContainer section to add fields or embed a section that displays the status of the external investigation case.