Stripe plans to ship improvements to Radar rules at the end of May 2024 to make it easier to understand and handle the behavior when attribute values are missing.

Currently, if you wrote a rule like Block if :email_domain: != ‘notfraud.com’ and :email_domain: was missing, this rule would not match. This is because Stripe interprets != 'notfraud.com' as the attribute having some explicit value other than 'notfraud.com', which a missing attribute wouldn't satisfy. Conversely, if you wrote a similar rule like Block if NOT(:email_domain: = ‘notfraud.com’) and the :email_domain: was missing, this rule would match. This is because the nested :email_domain: = ‘notfraud.com’ statement would evaluate to false, which when negated by the NOT operation would evaluate to true.

However in the new interpreter, both rules would result in the rule not matching. This is because any comparison (for example =, !=, >, <, IN) of a missing attribute against another static value or attribute (missing or present) respects that data is missing. Similarly, any logical operation (like AND, OR, NOT) with missing values results in a missing attribute unless explicitly defined. Any rule that results in a missing value being respected through the entire evaluation will not match.

You can identify rules that will be impacted by this change by reviewing predicates that use a NOT negation with a nested attribute that could potentially be missing. If you wanted to maintain the same matching behavior of Block if NOT(:email_domain: = ‘notfraud.com’), the way to do this would be to explicitly change your rule predicate to handle missing values: Block if is_missing(:email_domain:)OR NOT(:email_domain: = ‘notfraud.com’). Otherwise, your rule will automatically adopt the updated behavior once Stripe rolls out the May 2024 change.