Prevenir contra el abuso de OTP en el flujo de registro de aplicaciones

Esto puede sonar como una pregunta abierta, pero me gustaría arriesgarme y entender si hay alguna forma en que el resto de la comunidad esté manejando este problema.

Digamos que hay una aplicación que permite a los usuarios registrarse usando su número de teléfono.

Plataforma de aplicaciones

1. Android
2. iOS

Flujo de aplicaciones

1. el usuario abre la aplicación
2. se le presenta un usuario de inicio de sesión / botón de registro
3. ahora quiere registrarse ya que es un nuevo usuario. Así que hace clic en el botón de registro y se le pregunta su número de teléfono
4. cuando envía su número de teléfono, recibe una OTP a través de SMS. Digamos que la aplicación realmente llama al /register API, que es el que activa el SMS.

Riesgo: Ahora por cada SMS saliente, hay un costo financiero involucrado.

Medidas de mitigación proactivas / reactivas

1. La API tiene una tasa limitada (según el número de teléfono)
2. Hay un monitoreo y alerta adecuados en su lugar. Entonces, si hay casos de abuso, pueden ocurrir medidas extremas como el bloqueo de IP.

Issues

1. Si un adversario (potencialmente un competidor) golpea la API con diferentes números de teléfono, la lógica de limitación de velocidad se omite fácilmente.
2. El bloqueo de IP puede no ser viable todo el tiempo. Decir si el adversario está detrás de una red con NAT, todos los usuarios genuinos detrás de la red también serán bloqueados para que no se registren correctamente.
3. Si el adversario cambia las IP (tal vez utilizando Tor), el paso de mitigación 2 mencionado anteriormente también se omite.
4. Captcha no es una solución, ya que destruye UX, especialmente cuando se trata de aplicaciones móviles.
5. Tener una contraseña de nombre de usuario en lugar de OTP para la verificación del registro no es una opción porque la aplicación necesita un número de teléfono verificado para funcionar.
6. La firma por dispositivo también se puede usar como un factor para limitar la tasa, pero el hecho es que también proviene del dispositivo a través de HTTP (s). Por lo tanto, fácilmente cambiable también. Así que esta opción también está descartada.

En tal situación, ¿cómo protegerse contra el riesgo o quizás planificar y prepararse para ello, si es que no se puede clasificar?