Introduction to Scam Transaction Monitoring

Scam Transaction Monitoring is powered by a Machine-Learning model developed by FeatureSpace that provides clients with a risk score against each payment (inbound or outbound), showing how likely it is to be originating from a scam.

Scam Transaction Monitoring enables businesses to assess potential inbound and outbound scams in real-time. For potential outbound scams, Scam Transaction Monitoring checks if a payer is making a payment under the false pretence, for example if a payer got scammed. For potential inbound scams, Scam Transaction Monitoring checks if the funds are coming from a victim of a scam into the scammer’s account.

What is a Scam?

A scam is an authorised push payment fraud where the account holder authorised payment to be sent to a "scammer"/ "fraudster" (For example, romance scam, investment scam, purchase scam). Scams differ from fraud, which is where an account holder did not authorise the payment themselves (For example, in cases of account takeover, stolen account details).

How it Works

Scam Transaction Monitoring is intended to be used to assess risk at the level of an individual payment. It is recommended that Scam Transaction Monitoring is positioned as the last step before the payer's Funding Institution (FI) sends a payment through to the payee’s Funding Institution. Any other checks done by the FI (such as policy checks) should be done by the FI prior to sending the payment message to Scam Transaction Monitoring, with only approved payments being sent to Scam Transaction Monitoring.

It is expected that Scam Transaction Monitoring will receive approved payments (such as payments that pass a balance check). However, for certain use cases, an FI may wish to send in Failed or Cancelled payments for risk-scoring and further analysis, or to provide an update on the payment after it was made.

The figure below describes the suggested outbound scam transaction monitoring flow.

Figure 1: Outbound Scam Transaction Monitoring Flow

The figure below describes the suggested inbound scam transaction monitoring flow.

Figure 2: Inbound Scam Transaction Monitoring Flow

Historical payment data should not be uploaded to Scam Transaction Monitoring as it does not improve Scam Transaction Monitoring performance and can affect system performance.
To support a migration from another Transaction Monitoring tool, we recommend that Scam Transaction Monitoring is run silently for a period of time. For more information, contact your Implementation Manager.

Interpreting the Score

The real-time response from the Scam Transaction Monitoring API includes a risk score in the range of 0.0 to 1.0. For example, a score of 0.2 represents a lower scam risk and 0.8 represents a higher scam risk. Scam Transaction Monitoring is designed to offer an Exponential score calibration by default. The Exponential score calibration approximately halves the decline rate every 0.071 increase in the score, at least for decline rates smaller than 0.1%.

Examples of thresholds are provided in the table below. You can choose the score threshold, how to use it in your existing analytics, and associated downstream actions that are appropriate.

For example, if payment is declined at a score threshold of 0.706, the approximate expected decline rate across all payments for the FI that are risk scored by Scam Transaction Monitoring is 0.10% or 1 in 1000 payments. The model is regularly calibrated to reflect the expected decline rates as well as the expected value detection rates.

Decline Rate (basis points)

Score Threshold

1

0.900

5

0.771

10

0.706

25

0.615

50

0.545

100

0.474

Setting up Scam Transaction Monitoring

Before you can use Scam Transaction Monitoring in the Fraud Transaction Monitoring Portal, you must first complete the following:

  • Set up client authentication to connect to Thredd. For more information, see the Key Concepts guide.

  • Provide details to Thredd in the pre-agreed schema format in order to receive the risk score and related output action tags. For more information, see Scam Transaction Monitoring Schema.

  • Consider how your business will process the real-time response from the Scam Transaction Monitoring API and how the score will be used to augment your decisioning. This includes automated or manual treatments you employ depending on your risk appetite thresholds, such as:

    • Blocking or holding the payment

    • Freezing the account

    • Manual review in a case management system

    • Customer contact

Feedback Requirements for Scam Transaction Monitoring

For Scam Transaction Monitoring to remain performant and provide the best results, we recommend that at least 90% of confirmations of fraud or scam (For example, fraud labels) are returned to Scam Transaction Monitoring within 30-40 days.

There are two ways to send feedback:

  • Using the paymentTransactionReturn API endpoint

  • Marking an event as a Risk in the Fraud Transaction Monitoring Portal. If there is an alert generated, then mark it as Risk, including information if it’s a Fraud or Scam. If there is no alert generated, click on the Eye icon for payment event, create an Alert and then mark it as Risk, including information if it’s a Fraud or Scam.

It is a requirement to send feedback using one of these channels whenever a scam or fraud occurs. However, it is important that the feedback is not shared using both channels, as double counting can occur and this can impair the system’s performance.

Scam Transaction Monitoring only expects feedback in cases of fraud or scam. There is no need to send feedback if the payment was genuine.

Scam Transaction Monitoring expects the feedback to be sent even if the payment was declined or cancelled after it has been risk-scored.