Summary

  • Twilio Fraud Guard Promise는 막았어야 할 SMS 펌핑 메시지가 발송된 경우 해당 Verify 및 SMS 요금을 크레딧으로 처리할 수 있다고 정한다. Max Protection Mode를 계속 켜고, 발송 월이 끝난 뒤 30일 안에 지원 티켓을 내며, Twilio의 심사를 통과해야 한다.
  • 부정 전송의 영향을 받은 번호에는 Verify Geo Permissions, Safe List, RiskCheck 매개변수가 활성화되지 않아야 한다. 이 기능들은 정상 이용자의 잘못된 차단을 줄이는 데도 쓰인다.

한 번호를 구하면 다른 장부가 움직인다

고객에게 로그인 코드가 도착하지 않는다. 운영자가 번호를 Safe List에 넣으면 Fraud Guard나 지역 권한 설정의 차단을 피할 수 있다. Twilio가 제품 문서에서 안내하는 대응이다. 그런데 같은 번호가 SMS 펌핑 청구의 대상이 되면, 보전 약관은 그 목록을 크레딧 자격을 바꾸는 설정으로 본다. 상담 화면의 작은 조치가 재무팀이 기대한 안전망의 범위를 바꿀 수 있다.

Fraud Guard는 평소와 다른 트래픽 양상을 찾아 의심스러운 SMS를 막는다. Promise가 다루는 것은 막았어야 했는데 실제로 발송된 부정 메시지의 Verify 및 SMS 요금이다. Twilio는 청구 내용을 살펴 인정 여부를 결정한다. 대시보드의 ‘추정 절감액’은 차단된 시도에 근거한 지표이며, 실제로 승인된 크레딧과는 다른 장부에 적어야 한다.

첫 번째 경계는 보호 수준이다. 문서상 기본값은 Standard이지만, 비용 보전은 Fraud Guard를 Max Protection Mode로 켜고 계속 유지해야 한다. Max는 더 공격적으로 차단하며 Twilio도 정상 번호가 가끔 잘못 막힐 수 있다고 설명한다. 가입 전환율을 높이려고 차단을 누그러뜨리는 결정은 보전 조건에도 영향을 준다. 제품팀과 재무팀이 서로 다른 회의에서 이 결정을 내려서는 곤란하다.

두 번째 경계는 계정 전체가 아니라 부정 전송의 영향을 받은 번호다. 약관은 그 번호에 Verify Geo Permissions, Safe List, RiskCheck 매개변수를 사용하지 않았을 것을 요구한다. API 문서에는 RiskCheck 설정으로 SMS 인증 시도 하나의 부정 방지 조치를 우회할 수 있다고 나온다. 따라서 한 번호의 예외만으로 모든 청구를 재단할 수 없다. 제3자를 위해 전송하는 계정과 자체 인증 코드를 쓰는 고객에게는 별도 조건도 있다.

발송이 이뤄진 달력상 월말부터 30일 안에 지원 티켓을 제출하고 필요한 정보를 제공해야 한다. Twilio는 펌핑 여부와 Max가 막았어야 하는지를 판단한다. 공개 문서에는 승인 비율이나 특정 고객의 손실액이 없다. 실제 건의 판단을 바꾸는 자료는 피해 번호의 설정 이력과 Twilio의 결정이다. 사건이 터진 뒤 직원의 기억을 찾아다니는 것은 너무 비싼 기록 방식이다.

Sources