TL;DR

WP fail2ban Free counts authentication failures inside each XML-RPC request. One failure remains an ordinary failed login; the second stops the request and becomes a hard event that fail2ban can enforce at the host firewall.

You can keep XML-RPC available for legitimate clients without letting one request hide a bundle of failed logins. Premium also preserves the multicall event for monitoring and investigation.

Count the attempts inside the request

A web-server log sees one connection and one HTTP request. That is not enough to show how many XML-RPC authentication attempts the body contained.

WordPress processes the individual method calls and knows when each authentication attempt fails. WP fail2ban uses that application context to count the failures inside the bundle rather than treating the request as a single event.

Let the first failure remain ordinary

A legitimate client can present an old password or make another isolated authentication mistake. One XML-RPC failure has the same ambiguity as one failed login elsewhere.

A second authentication failure inside the same multicall request means one request now contains repeated authentication attempts. That gives WP fail2ban enough confidence to stop it and produce a hard event.

Stop the bundle before it continues

WP fail2ban terminates the request when the second failure is detected. The attacker does not get to use the rest of the bundle merely because all of its calls arrived through one connection.

A configured fail2ban jail can then block the source at the host firewall, preventing another bundled request from reaching WordPress.

Protect an interface you still need

Sites with no use for XML-RPC can close it completely. The multicall control protects sites that keep the interface available and is included in WP fail2ban Free. Premium can additionally restrict the endpoint to Jetpack, trusted sources, or pingbacks and keeps the multicall event available for investigation.

More about XML-RPC policy.