Route Risky Signups Automatically With n8n

The article discusses the limitations of a simple IF node approach to preventing signup fraud in n8n. The IF node only blocks signups if they are using a VPN, which fails in a few key cases. Corporate gateways, privacy relays like iCloud Private Relay, and residential proxies are not caught by an IF node that checks for is_vpn.

Instead, the article recommends assigning a threat score to each signup based on various security checks. The score ranges from 0-100 and is accompanied by 28 additional fields describing the security checks performed. The score and flags need to be evaluated in a specific order:

- Scores 1-19 are allowed with standard controls

- Scores 20-44 require additional verification like email confirmation

- Scores 45-79 trigger friction points like review or friction before allowing login

- Scores 80-100 result in blocking or manual review

Corporate gateways and privacy relays need special handling before the score is processed. A corporate gateway IP should not be blocked but rather flagged appropriately. Privacy relays are allowed without blocking, as they are not trying to hide the user. Residential proxies are evaluated but not automatically blocked, as their high score indicates suspicious activity that requires additional review.

The article emphasizes that the security flags provide more context than the raw threat score alone. Confidence scores for VPNs, relays, and other checks show how reliable each detection is. These confidence scores should guide whether to trigger more friction like an OTP or outright block the signup.

The workflow should be a webhook trigger followed by a lookup node to get the security details, an override check to handle corporate gateways and relays first, then a Switch node with four outputs based on the score and flags. This approach scores each signup and handles edge cases more accurately than a simple VPN check, ensuring legitimate users aren't blocked while still preventing fraud.