Introduction to the Fraud Alert Service

The Fraud Alert Service delivers fraud notifications to your systems. You can then use these notifications to create alerts for your cardholders through their preferred channels, such as in-app notifications, to warn them about potential fraud incidents.

To use the Fraud Alert Service, webhooks are used to deliver fraud notifications to your systems. Speak to your Implementation Manager to register for this service, or see Introduction to Webhooks for more information.

The Fraud Alert Service Workflow

When this has been successfully set up, and you have opted for in-app fraud notifications, the Fraud Alert Service will notify you when any potential fraudulent transaction takes place. The steps are as follows:

1. A potentially fraudulent transaction occurs.
2. If you have opted for in-app fraud notifications, the Fraud Detection System transmits the fraud notification to Thredd.
3. Thredd sends the fraud notification as a webhook event to your designated client endpoint.
4. Your systems processes the notification, relay it to the cardholder through in-app notifications, and await for the cardholder's acknowledgment to authenticate the transaction.
5. The cardholder responds to the notification.
6. Your systems send the cardholder's response back to the fraud detection system for processing the cardholder's response.

See the below example response for each of the different events.

{
  "context": {
    "notificationId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "eventCode": 101,
    "eventVersion": "v1",
    "notificationTime": "2024-01-24T23:20:28Z"
  },
  "payload": {
    "fraudAlertId": "05e991e3-9058-4d79-bf01-76d4e8fe2059",
    "productId": 123,
    "transactionId": 98765432101212,
    "tokenId": 545454121,
    "transactionAmount": "50.75",
    "currency": "USD",
    "merchantName": "Sample Merchant",
    "location": "United Kingdom",
    "dateTime": "2024-01-24T14:30:00Z",
    "mcc": "4567",
    "notificationMessageContent": "Did you attempt $50.75 on card ending 1234 at Example Merchant ? We suspect fraud and blocked the card, Acknowledge if you made this purchase."
  }
}

{
  "context": {
    "notificationId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "eventCode": 102,
    "eventVersion": "v1",
    "notificationTime": "2024-01-24T23:20:28Z"
  },
  "payload": {
    "fraudAlertId": "05e991e3-9058-4d79-bf01-76d4e8fe2059",
    "fraudAlertType": "Acknowledgement",
    "notificationMessageContent": "From Bank: Thank you for replying. Your card ending 1234 has been unblocked.",
    "productId": 123
  }
}

📘

Information

For more information on the fields used in the response of the Fraud Events, see the following pages:

• For Fraud Detection Events, see Fraud Detection Events - Field Descriptions.
• For Fraud Action Events, see Fraud Action Events - Field Descriptions.

Available Webhooks

The following table describes each of the available endpoints for the Fraud Alert Service.

Create Fraud Alert Response

The Fraud Alert Response endpoint enables you to deliver feedback regarding a fraud alert, primarily consisting of the cardholder's response to the fraud alert.

You can create a fraud alert response by making a POST request to the Fraud Alert Response endpoint. For example:

{base-url}/eds/api/v1/fraudalertresponse

The POST body should include the details of the cardholder's response. For example:

{
"fraudAlertId": "af5d48de-2ad7-62f8-a252-743cd9e6078",
"notificationId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
"response": "YES"
}

If successful, a 200 response is returned. See the below example.

{
"status": "success",
"response": "The request was successful"
}

📘

Note

If the customer does not respond (or if API is not sent) in 72 hours, the alert is marked as “no response” (a respective transactionReturn message appears in Fraud Portal). The alert itself remains open, but the customer won’t be able to trigger the alert closure/card unblock via the App if they try after this time period.

Note that in the UAT environment, the time-out is set to 5 minutes.

👍

Information

See Fraud Alert Response - Field Descriptions to see details on the fields included in the request and the response.

Testing Fraud Alert Response

Fraud Alerts testing is available in our UAT environment. These scenarios are representative of the scenarios that happen in Production for different set of rules that trigger Decline and DeclineAndBlock output action tags. When these are tested, the system behaves in exactly the same manner from Fraud Alerts standpoint for all other rules.

📘

Note

There can be a slight delay in an alert being closed and the alert being updated in the Fraud Portal. If the alert is open in full view by an agent, the alert will not be automatically closed and will be closed after the full view is closed. This is to prevent a potential mismatch between agent closing an alert vs an API.

When the the alert response is sent back by the customer, all the alerts related to the card will be marked as closed with the same confirmation of fraud. This is due to alerts coming through for individual transactions where the risk is small that fraud will be missed when closing other alerts, allowing for better operational efficiencies.

The following pre-requisites are required for testing in the UAT environment:

• Connectivity has been established with the Thredd environment (preferred method of connectivity is mTLS).
• Registration for webhooks is complete.
• Access to UAT testing tool is available (Such as CTS. Contact your Account Manager if you do not have access).
• Fraud alert test fraud rules are set up in UAT (this is done by Thredd Fraud Operations team).
• A Product ID to conduct testing with is shared with Thredd team.

Example Test Scenario - Decline Only

The following is an example test scenario flow for testing a Decline-only alert:

1. Send a transaction with a value of GBP 6.00 using a card with the pre-agreed Product ID.
2. The Transaction will be declined due to a fraud rule AND a webhook notification. An In-App notification is sent to the client service.
3. When received, the customer responds with Yes or No, initiating a Fraud Alert Response API call:
   1. If a customer responds with Yes (it was me), then the card remains unblocked and the cardholder can try to complete a transaction again.
   2. If a customer responds with No (it wasn’t me), then the card is blocked (G5 block).
4. The Alert is auto-closed with a confirmed Risk/No risk.
5. The Acknowledgement webhook is sent. (This step happens in parallel to step 4).

Example Test Scenario - Decline and Block

The following is an example test scenario flow for testing a Decline and Block alert:

1. Send a transaction with a value of GBP 12.00 using a card with the pre-agreed Product ID.
2. The Transaction is declined due to a fraud rule AND the card will be blocked AND a webhook notification/In-App notification is sent to the client service.
3. When received, the customer responds with Yes or No, initiating a Fraud Alert Response API call:
   1. If a customer responds with Yes (it was me), then the card is unblocked and the cardholder can try to complete a transaction again.
   2. If a customer responds with No (it wasn’t me), then the card remains blocked.
4. The Alert will be auto-closed with a confirmed Risk/No risk.
5. An acknowledgement webhook is sent. Note this step happens in parallel with step 4.

📘

Frequently Asked Questions

To view frequently asked questions related to the Fraud Alert service, see Fraud Alert Response FAQs.