Visa fraud monitoring

From PegaWiki
Visa Fraud Monitoring Program / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Visa fraud monitoring

Description Configurations of Visa fraud monitoring process
Version as of 7.4
Application Pega Disputes and Payments Exceptions
Capability/Industry Area Financial Services



Visa Fraud Monitoring Program[edit]

This topic defines the process of automatic claim creation by VFMP agent in the Smart Dispute application.

Use case examples[edit]

Visa monitors transactions and marks some transactions as potential frauds based on past fraud history and running an internal algorithm. A report of the transactions is sent to the Issuer banks.

Issuing banks have an option of disputing these transactions either by an internal inquiry or by confirming with cardholder. Smart Dispute creates a single claim with multiple disputes (multiple child objects under a single parent) for transactions received from Visa at each iteration and redirects them to a specific work group. This specific work group either takes the dispute ahead and submits it to Visa or resolves the dispute as a legitimate transaction.

Before you begin[edit]

Issuer/Issuing Bank: The bank or financial institution that issues the credit or debit card to the account or card holder.

Posted Transactions: Transaction that has been posted to cardholder's account.

DMT: Dispute Multiple Transactions.

Process/steps to achieve objective[edit]

VFMP stands for Visa Fraud Monitoring program. To enable automatic claim creation for potential frauds that fall under 10.5, Create Visa 10.5 Disputes agent in PegaCardSdVisa ruleset must be enabled.

This agent invokes the VCR_VFMPProcessor activity, which takes care of the processes below:

  1. Logic of reading JQueue (potential fraud transactions-'GMFP_ITEMS') from the Visa service GetQueueOperation response.
  2. The application marks and sends the transactions to Visa by calling the IgnoreGMFPOperation service. Visa marks them to avoid sending those transactions again.
  3. The application checks if the transaction has been posted to cardholder's account by scanning through transactions table. The CreateDisputesForVisa10_5 activity takes care of claim creation logic for all fraud transactions posted to card holder under a single claim. The activity also updates the respective claim id created in transactions table against each transaction.

Results[edit]

Issuer banks can read and create claims for all potential frauds posted to cardholder accounts without any manual intervention.