Enable Anti-Fraud Workflows
Plans: Premium, Enterprise Platforms: All platforms
With AfterShip Return’s Fraud Prevention feature, you can set up automation rules to stop or minimize fraudulent return activities with specific conditions and actions in place. These conditions help detect and flag suspicious return requests for manual review.
In this article, we will show you:
Anti-fraud workflows benefits
How to enable fraud prevention
How to set up anti-fraud workflows
- Create new workflows
- Use pre-built workflows
View anti-fraud automation records
Anti-fraud workflows can analyze return data to identify patterns indicative of wardrobing, such as a high frequency of returns for specific items or a pattern of returns shortly after purchase. By detecting these suspicious patterns, businesses can flag potential instances of wardrobing for further investigation or completely blocklisting customers from raising any returns in the future.
Anti-fraud workflows can also detect instances where customers attempt to return an empty box instead of the actual product. By analyzing a specific data point, package weight, these workflows can flag suspicious returns for further inspection.
To set up anti-fraud workflows, you first need to enable fraud prevention.
Go to Return policy in the AfterShip Tracking admin.
Move to the Fraud prevention section on the sidebar.
Click Enable fraud prevention to activate and set up two major aspects of this toolkit.
Once enabled, the Fraud prevention settings dashboard will open, allowing you to configure the following settings.
Request history display
Anti-fraud workflows
Click Create workflow to build a workflow from scratch.
Name the workflow for easy reference by simply clicking on the default name to make it editable.
On the left side panel, you can set up Conditions and Actions.
On the Preview window, you can see how your workflow will function based on the defined conditions and the actions that will consequently be taken.
Click Add condition to expand the conditions menu.
Select the condition and input the values based on your goals.
Once conditions are set up, click anywhere on Apply section box on the preview window to open the Actions configuration side panel.
Click Add action to expand the actions menu.
Select the action that will be triggered once the defined conditions are met.
Click Save draft to save the workflow but not activate it.
Click Enable to activate the workflow.
CONDITIONS are triggers based on which a certain action will set off. You can set up conditions from either of the three groups and the selected action will be taken.
The conditions are categorized into three groups
Group 1: Conditions related to the frequency of the return request with specific attributes.
Group 2: Condition related to the weight of the return package, helpful in the event of empty box fraud.
Group 3: Condition related to the return tracking updates date in relation to return request submission date to identify the Fake tracking ID (FTID) return fraud.
Supported conditions
Carriers supporting weight information
The following carrier most likely contain actual package weight in their tracking information
You can use other carrier services but if the package weight is missing, it will not trigger a workflow.
Important things to remember when setting up conditions
Each workflow can only use a single group condition. You can use different group conditions in the same workflow. Once a condition from a specific group is selected, conditions that belong to other groups will be greyed out.
To employ the return weight condition effectively and prevent false triggers:
Ensure the accurate item weight is configured in the eCommerce platform.
When setting up the weight difference, ensure to include a buffer for the weight of the return box.
If all the conditions in Group 1 are configured in the same workflow, the action will be triggered if one of the conditions are met.
ACTIONS are responses that will be triggered when the conditions are matched.
Supported actions
Every action within a single workflow must be processed.
Each action will be triggered only once per return request.
Drag and drop the workflow to your desired position on the list to set its priority.
In cases where multiple workflows contain the same actions, the one with higher priority will be triggered.
In this example, there are three workflows with different priorities and actions related to processing return requests:
Workflow 1 (Priority 1): This workflow has the action "Add to blocklist," indicating that if its conditions are met, the customer's email will be added to a blocklist, preventing them from submitting returns in the future.
Workflow 2 (Priority 2): This workflow includes two actions: "Add to blocklist" and "Flag return." If its conditions are met, the customer's email will be added to the blocklist, similar to Workflow 1, and the return request will also be flagged for manual review.
Workflow 3 (Priority 3): This workflow only has the action "Flag return." If its conditions are met, the return request will be flagged for manual review.
Now, let's consider a scenario where a return request meets the conditions for all three workflows:
Result: Since Workflow 1 has the highest priority, it will be triggered first, adding the customer's email to the blocklist. Then, Workflow 3 will be triggered, flagging the return request for manual review.
Outcome: As a result, the RMA (Return Merchandise Authorization) is flagged for manual review, indicating that it requires human intervention before further processing. Additionally, the customer's email is added to the blocklist, preventing them from submitting returns again in the future.
The instances of wardrobing and empty box return frauds as per the studies are the highest with eCommerce businesses. To combat these instances most efficiently and save you time, we have pre-built workflow templates for preventing empty box and wear and return frauds to help you quickly activate these flows and manage return requests effectively to prevent potential fraud or abuse.
1. Prevent wear and return
Mitigate fraud by adding the customer’s email address to the blocklist if there are suspiciously high frequency of returns for specific items with specific reasons shortly after purchase during the specified time period.
Option 1:
Condition: Return reason (for example: Poor quality/faulty); Number of requests (for example: >15 in the last 180 days)
Action: Add customer to blocklist
Option 2:
Condition: Return item tag (for example: Sale); Number of requests (for example: is between 5 to 10 in the last 90 days)
Action: Add customer to blocklist
Item tags will be synced from your AfterShip Returns admin
If you wish to set up a different action, say Flag request for review for recurring requests with specific tags, you need to set up a new workflow.
2. Prevent empty box
Prevent losses by having your warehouse manually inspect the item if the recorded weight of the return package significantly deviates from the expected weight of the item being returned to ensure the customer is not attempting to return an empty box instead of the actual product.
Condition: Return weight difference from the original package is for example, greater than 1 kg
Action: Flag request for review
Fake tracking number return fraud involves a scam where a customer provides a fake or invalid tracking number when returning an item to an eCommerce retailer.
How it typically works
A customer buys a product from an online retailer.
Once the product is delivered, the customer decides to return it under the pretense of it being defective or different from what was promised online.
The customer provides the retailer with an invalid or fake tracking number instead of returning the actual item, making it appear as though the returned item is in transit.
The retailer initiates the refund or replacement upon receiving the tracking number.
The retailer never gets the returned item back since the customer never sent the item back and instead shared a fake and invalid tracking number. The customer receives a refund or replacement without actually returning the product.
Workflows that could detect the tracking updates where the receipt of a return package took place before the date the return request was originally initiated or approved can significantly help merchants in combating fake tracking number return fraud.
Here how you can set up the rules to detect fake tracking number return fraud.
Condition: First return tracking update date is {1 day} before return request date
Action: Flag request for review
When an anti-fraud automated workflow is activated or triggered, you can see and review the history or log of that workflow under the Anti-fraud automation records. You can see a record of the actions taken by the automation, including the RMA for which the automation was triggered, when it was triggered, what actions were performed, and any relevant details or outcomes associated with those actions.
To access these records, click View automation records on the Fraud prevention configuration page.
Display customer request history on RMA detail page
Overview
With AfterShip Return’s Fraud Prevention feature, you can set up automation rules to stop or minimize fraudulent return activities with specific conditions and actions in place. These conditions help detect and flag suspicious return requests for manual review.
What you’ll learn
In this article, we will show you:
Anti-fraud workflows benefits
How to enable fraud prevention
How to set up anti-fraud workflows
- Create new workflows
- Use pre-built workflows
View anti-fraud automation records
How anti-fraud workflows are beneficial?
Anti-fraud workflows can analyze return data to identify patterns indicative of wardrobing, such as a high frequency of returns for specific items or a pattern of returns shortly after purchase. By detecting these suspicious patterns, businesses can flag potential instances of wardrobing for further investigation or completely blocklisting customers from raising any returns in the future.
Anti-fraud workflows can also detect instances where customers attempt to return an empty box instead of the actual product. By analyzing a specific data point, package weight, these workflows can flag suspicious returns for further inspection.
To set up anti-fraud workflows, you first need to enable fraud prevention.
Enable fraud prevention
Go to Return policy in the AfterShip Tracking admin.
Move to the Fraud prevention section on the sidebar.
Click Enable fraud prevention to activate and set up two major aspects of this toolkit.
Once enabled, the Fraud prevention settings dashboard will open, allowing you to configure the following settings.
Request history display
Anti-fraud workflows
Set up anti-fraud workflows
A. Create new workflows
Click Create workflow to build a workflow from scratch.
Name the workflow for easy reference by simply clicking on the default name to make it editable.
On the left side panel, you can set up Conditions and Actions.
On the Preview window, you can see how your workflow will function based on the defined conditions and the actions that will consequently be taken.
Click Add condition to expand the conditions menu.
Select the condition and input the values based on your goals.
Once conditions are set up, click anywhere on Apply section box on the preview window to open the Actions configuration side panel.
Click Add action to expand the actions menu.
Select the action that will be triggered once the defined conditions are met.
Click Save draft to save the workflow but not activate it.
Click Enable to activate the workflow.
Conditions
CONDITIONS are triggers based on which a certain action will set off. You can set up conditions from either of the three groups and the selected action will be taken.
The conditions are categorized into three groups
Group 1: Conditions related to the frequency of the return request with specific attributes.
Group 2: Condition related to the weight of the return package, helpful in the event of empty box fraud.
Group 3: Condition related to the return tracking updates date in relation to return request submission date to identify the Fake tracking ID (FTID) return fraud.
Supported conditions
| Condition | Description | Logic | Condition group |
|---|---|---|---|
| Number of return requests | Counts the return requests for the specified period. The action will be triggered immediately after the RMA creation. | is greater than, in between | Group 1 |
| Number of requests with specific reasons | Counts the return requests with specific reasons for the specified period. The action will be triggered immediately after the RMA creation. | is greater than, in between | Group 1 |
| Number of requests with specific item tags | Counts the return requests with specific item tags ( Tags you have added in the AfterShip Returns admin) for the specified period. The action will be triggered immediately after the RMA creation. | is greater than, in between | Group 1 |
| Return weight difference from the original package | Compares the weight between the return shipment and selected item. The action will be triggered once the return shipment is created/uploaded with weight information. Works well with certain carriers. Find the complete list below. | is greater than, in between a specified weight in kgs or lbs | Group 2 |
| First return tracking update date | Compares the the date of first return shipment checkpoint and return request/approval date. The action will be triggered once the first checkpoint date is generated. | is {n} number of days before the return request creation or approval | Group 3 |
Carriers supporting weight information
The following carrier most likely contain actual package weight in their tracking information
You can use other carrier services but if the package weight is missing, it will not trigger a workflow.
| Carrier name | Slug |
|---|---|
| FedEx R | fedex, fedex-api |
| UPS | ups, ups-api |
| UPS Mail Innovations | ups-mi |
| USPS Flats (Pitney Bowes) | pb-uspsflats-ftp |
| Aramex | aramex-api |
| ASM(GLS Spain) | asm |
| OnTrac | ontrac |
| Posti | posti |
| TopYou | topyou |
| DeliverDirect | smartkargo |
| United Delivery Service | uds |
| XDP Express | xdp-uk |
| Seino | seino-api |
| Correos Express | correosexpress-api |
| Parcelstars | parcelstars-webhook |
| Landmark Global | landmark-global-ftp |
| Bpost | bpost-api |
| VicTas Freight Express | vtfe |
| Veho | veho-webhook |
| OrangeDS (Orange Distribution Solutions Inc) | orangedsinc-ftp |
| SG LINK | sglink |
| Tomydoor | tomydoor |
Important things to remember when setting up conditions
Each workflow can only use a single group condition. You can use different group conditions in the same workflow. Once a condition from a specific group is selected, conditions that belong to other groups will be greyed out.
To employ the return weight condition effectively and prevent false triggers:
Ensure the accurate item weight is configured in the eCommerce platform.
When setting up the weight difference, ensure to include a buffer for the weight of the return box.
If all the conditions in Group 1 are configured in the same workflow, the action will be triggered if one of the conditions are met.
Actions
ACTIONS are responses that will be triggered when the conditions are matched.
Supported actions
| Action | Description |
|---|---|
| Flag request for review | Flag request for manual review, and no automation rule will be triggered even after unflagging the return request. |
| Add customer to blocklist | Add the customer email to blocklist to prevent the customer from raising any new return request. |
Workflow priority rule
Every action within a single workflow must be processed.
Each action will be triggered only once per return request.
Drag and drop the workflow to your desired position on the list to set its priority.
In cases where multiple workflows contain the same actions, the one with higher priority will be triggered.
In this example, there are three workflows with different priorities and actions related to processing return requests:
Workflow 1 (Priority 1): This workflow has the action "Add to blocklist," indicating that if its conditions are met, the customer's email will be added to a blocklist, preventing them from submitting returns in the future.
Workflow 2 (Priority 2): This workflow includes two actions: "Add to blocklist" and "Flag return." If its conditions are met, the customer's email will be added to the blocklist, similar to Workflow 1, and the return request will also be flagged for manual review.
Workflow 3 (Priority 3): This workflow only has the action "Flag return." If its conditions are met, the return request will be flagged for manual review.
Now, let's consider a scenario where a return request meets the conditions for all three workflows:
Result: Since Workflow 1 has the highest priority, it will be triggered first, adding the customer's email to the blocklist. Then, Workflow 3 will be triggered, flagging the return request for manual review.
Outcome: As a result, the RMA (Return Merchandise Authorization) is flagged for manual review, indicating that it requires human intervention before further processing. Additionally, the customer's email is added to the blocklist, preventing them from submitting returns again in the future.
B. Use pre-built workflows
The instances of wardrobing and empty box return frauds as per the studies are the highest with eCommerce businesses. To combat these instances most efficiently and save you time, we have pre-built workflow templates for preventing empty box and wear and return frauds to help you quickly activate these flows and manage return requests effectively to prevent potential fraud or abuse.
1. Prevent wear and return
Mitigate fraud by adding the customer’s email address to the blocklist if there are suspiciously high frequency of returns for specific items with specific reasons shortly after purchase during the specified time period.
Option 1:
Condition: Return reason (for example: Poor quality/faulty); Number of requests (for example: >15 in the last 180 days)
Action: Add customer to blocklist
Option 2:
Condition: Return item tag (for example: Sale); Number of requests (for example: is between 5 to 10 in the last 90 days)
Action: Add customer to blocklist
Item tags will be synced from your AfterShip Returns admin
If you wish to set up a different action, say Flag request for review for recurring requests with specific tags, you need to set up a new workflow.
2. Prevent empty box
Prevent losses by having your warehouse manually inspect the item if the recorded weight of the return package significantly deviates from the expected weight of the item being returned to ensure the customer is not attempting to return an empty box instead of the actual product.
Condition: Return weight difference from the original package is for example, greater than 1 kg
Action: Flag request for review
Detect fake tracking ID return fraud with workflows
Fake tracking number return fraud involves a scam where a customer provides a fake or invalid tracking number when returning an item to an eCommerce retailer.
How it typically works
A customer buys a product from an online retailer.
Once the product is delivered, the customer decides to return it under the pretense of it being defective or different from what was promised online.
The customer provides the retailer with an invalid or fake tracking number instead of returning the actual item, making it appear as though the returned item is in transit.
The retailer initiates the refund or replacement upon receiving the tracking number.
The retailer never gets the returned item back since the customer never sent the item back and instead shared a fake and invalid tracking number. The customer receives a refund or replacement without actually returning the product.
Set up anti-fraud workflow to detect fake tracking ID returns
Workflows that could detect the tracking updates where the receipt of a return package took place before the date the return request was originally initiated or approved can significantly help merchants in combating fake tracking number return fraud.
Here how you can set up the rules to detect fake tracking number return fraud.
Condition: First return tracking update date is {1 day} before return request date
Action: Flag request for review
Anti-fraud automation records
When an anti-fraud automated workflow is activated or triggered, you can see and review the history or log of that workflow under the Anti-fraud automation records. You can see a record of the actions taken by the automation, including the RMA for which the automation was triggered, when it was triggered, what actions were performed, and any relevant details or outcomes associated with those actions.
To access these records, click View automation records on the Fraud prevention configuration page.
Additional resources
Display customer request history on RMA detail page
Updated on: 19/07/2024
Thank you!