In short
Yes, because AIT is identified by destination behaviour rather than by message characteristics. Controls target the number ranges accumulating fabricated verifications — rate limits, quarantine, range-level review — rather than the sender or the message type, so genuine verification to real subscribers is unaffected.
Why the distinction makes it tractable
If AIT had to be identified by sender or content, mitigation would be impossible without collateral damage: the sender is a legitimate platform and the content is a legitimate OTP. Blocking either would break real verification for real subscribers.
Because the anomaly is in the destination ranges, controls can be applied there instead — and a real subscriber's verification message is not affected by a rate limit applied to a range they are not in.
Control options, least disruptive first
Most operators work down this list rather than starting at the bottom:
- Monitor and report — quantify the traffic and raise it with the enterprise and aggregator
- Rate-limit verification traffic to flagged destination ranges, capping exposure without stopping delivery
- Quarantine for review rather than dropping, preserving evidence and allowing reversal
- Apply range-level restrictions on verification categories specifically, leaving other traffic untouched
- Suspend delivery to confirmed ranges, once the analysis has been corroborated with the enterprise
Keeping false positives recoverable
Any of these controls applied to a wrongly identified range blocks real people from logging in to their bank. That is why quarantine is preferred over dropping, why enforcement is confirmed by an authorised engineer rather than applied automatically by a classifier, and why delivery rates for registered senders are tracked as a quality KPI alongside the blocked-volume figures.
In Guardivia's platform this is the standard governance sequence: the classifier proposes with evidence attached, an engineer confirms, and every decision carries a reason code that makes reversal straightforward.
The durable fix is upstream
Operator-side controls limit the damage; they do not remove the incentive. The lasting reduction comes from the enterprise side — rate limiting per user and per IP at the sign-up flow, CAPTCHA or risk scoring before a code is issued, and restricting verification to destination ranges the platform actually serves.
Operators that share their range-level findings with enterprises and aggregators get those upstream controls implemented, which is why AIT is better handled as a collaborative revenue-assurance programme than as a unilateral blocking exercise.