Modern banks often monitor payment transactions for their clients, looking for potential fraud or other exceptions that require escalation at the client firm before payment is released. The Payment Approval microjourney™ enables the escalation, review, and approval process through self-service, making the procedure more convenient for corporate clients and efficient for relationship managers.

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

Business value

Enable payment approval processing with self-services to help commercial bank customers be more efficient and thorough. Intuitive and straightforward approval processing enables banks to proactively notify chief financial officers (CFOs) and treasurers of potentially fraudulent payment transactions.

Required applications

You need one or both of these applications for this microjourney.

• Required – Pega Customer Service™ for Financial Services 8.4
• Optional – Pega Sales Automation™ for Financial Services or other application to receive alerts

Personas, channels and usage

Example usage

In the figures below, a transaction alert system has identified certain transactions or patterns of transactions that meet criteria for approval.

1. As a treasurer, when you log in to the web self-service portal of the bank, a list of payments that require approval is displayed in the mashed-up section.
   
   
2. When you open the alert, the following pane appears.
   
   
3. View additional details by expanding the row.
   
   
4. Click Show details to view the logic that shows why the transaction was flagged as well as any additional transaction information.
   
   
5. Click Approve payment or Stop payment.
6. If you click Stop payment, you have an option to open a fraud investigation, as shown below.
   
   

Stages and steps

There are three stages of the case flow as shown in the figure below:

1. Initate – Fraud detection logic in a payments system detects an exceptional payment and initiates the case for approval from the treasurer or CFO.
2. Approve payment – The treasurer receives an email notification and logs in to a web self-service portal of the bank to review the payment and take action to either approve or reject the payment.
3. Resolution – The necessary stakeholders (such as the relationship manager of the bank) receive a notification and the updated payment record updated.

Data model

The Data model tab of the Approve payment case type displays the data objects that are used.

Enabling the microjourney

At the minimum, this microjourney requires implementation of the GetDepositTransactions activity to get the list of transactions that need approval. Other extension points are described in the FAQs section of this document.

To get the list of transactions from an appropriate source, extend the GetDepositTransactions activity, which is provided as an extension point. By default, this activity gets the list of transactions from sample data sources in Step 2, as shown below.

FAQs

What are the common extensions?

This section lists and describes extension points in this microjourney that can add more integrations and automation in your implementations.

1. To get the primary email ID of the treasurer for a specific business unit, build the logic by extending the RouteToTreasurer data transform and update the value to the RouteTo property.

   
   
2. To get the operator ID of the treasurer, use the RouteToTreasurer activity, which is provided as an extension point, to build your own logic and update the value to the Param.AssignTo property.
   By default, the logic in this activity fetches the operator ID based on the primary email ID.
   
   
3. 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.
   
   
4. Extend the ReportFraud flow to customize the process to create a fraudulent case on a transaction when the treasurer selects the option to report fraud.
   
   
5. Extend the UpdateSOR flow to update the transaction details.