SoftTech AI Registry
Adyen · Adyen Protect

Machine Learning Bot Attack Blocking

Adyen Protect uses its documented machine-learning bot-attack risk rule to evaluate incoming payment attempts for suspicious automated activity, including unusually rapid attempts and patterns associated with card testing or enumeration. When the bot-attack rule identifies an attempt for blocking, Protect can block that payment before authorisation, subject to the risk-profile configuration and applicable rule precedence.

Recorded characteristics

Function
Adyen Protect uses its documented machine-learning bot-attack risk rule to evaluate incoming payment attempts for suspicious automated activity, including unusually rapid attempts and patterns associated with card testing or enumeration. When the bot-attack rule identifies an attempt for blocking, Protect can block that payment before authorisation, subject to the risk-profile configuration and applicable rule precedence. Model-owned decision: assessment that an incoming payment attempt is likely associated with suspicious automated attack activity. This is distinct from Protect's general transaction fraud-risk classification. The exact model architecture, score and internal threshold are not publicly established. Actions: Protect's bot-attack machine-learning rule has a documented Block action. Affected payment attempts can be stopped before authorisation without an individual human approval step. The model is not described as autonomously freezing shopper accounts, cards, payouts or merchant accounts. External actions: blocking changes whether the payment proceeds to authorisation; this is a consequential payment-processing action, not merely an internal alert. Human confirmation: not required for each automatic payment block. This does not mean merchant administrators have no configuration or oversight role.
Data access
Payment request fields, shopper data and available interaction information contribute to risk evaluation; Adyen stresses data quality for both the bot-attack and fraud-risk machine-learning rules. Access to all shopper information or a complete feature inventory is not established.
Actions
Can take actions
External actions
Yes
Human confirmation
Not required
Permission basis
Not established
Administrative control
Administrative risk configuration is governed by merchant/company risk settings and Customer Area roles such as Merchant change risk settings and Risk admin; authorised risk administrators can create and assign risk profiles. These administrative roles are not the bot model's runtime identity: the internal runtime execution identity and granular enforcement permissions are not publicly established. Adyen states the bot-attack machine-learning rule has no configuration options. Bot-rule-specific default activation is not publicly established; Basic/Premium eligibility and the availability of default risk profiles do not establish that the bot rule is enabled for every merchant by default.
Default state
Not established
Availability
Documented commercial Protect capability. The bot-attack machine-learning rule is listed for Protect Basic and Premium; the fraud-risk machine-learning rule requires Premium. Availability is conditional on a supported online payment integration, enabled risk management and an assigned risk profile. A separate Adyen help guide characterises Basic card-testing protection as rule-based; the version/tier relationship is unresolved.
Licensing
Not established
External model or provider
Adyen Protect machine-learning bot-attack risk rule. Model architecture, scoring method and internal threshold are not publicly established; separate deployed model infrastructure is not claimed.
Limitations and uncertainty
L01: The bot rule detects suspicious automated payment activity; no universal detection accuracy, false-positive rate or guarantee of stopping all card testing is established. L02: The exact model architecture, scoring method, feature weights, numerical cutoff and internal enforcement precedence are not publicly disclosed. L03: Adyen states the bot-attack ML rule has no configuration options. A merchant-adjustable bot threshold is not to be inferred. L04: General merchant risk-management settings exist, but bot-specific disablement and default activation are not publicly established. L05: Current Adyen technical documentation lists the bot ML rule for Basic and Premium. A separate Adyen help article characterises Basic card-testing protection as rule-based. The historical/version relationship is unresolved; it is not claimed that every Basic deployment has always used the same ML mechanism. L06: The action applies to payment attempts, not an autonomous account, card or payout restriction. L07: No independently controlled transaction-level experiment or internal-model counterfactual has been performed. The claim is grounded in first-party documentation. L08: Other configured Allow/Block rules and risk-profile precedence may affect the final processing result. The bot model is not claimed to have unrestricted enforcement priority. L09: Merchant/company administrative roles do not establish the internal runtime identity or exact permission scope of the ML rule. L10: Protect Premium fraud-risk threshold and general fraud classification belong to the existing Machine Learning Fraud Risk Blocking record (#172), not this capability.

Evidence