Антифрод в B2B SaaS: проверка номера через MAX против trial abuse и multi-account

Trial abuse, multi-account рефералка, фейковые регистрации под бесплатные лимиты — в B2B SaaS это не «потерянные пробники», как кажется со стороны. Это прямая инфляция CAC, нагрузка на поддержку и шум в продуктовых метриках, который ломает решения growth-команды. Самый дешёвый сигнал первой линии, который отсекает 8–15% явного мусора ещё до SMS OTP и до того, как абьюзер съел free-tier ресурсы, — проверка номера в мессенджере MAX за $0.005.

Эта статья — практический разбор для команд Trust&Safety, Growth и backend-разработчиков B2B SaaS: где MAX-проверка реально работает, где она бесполезна, как встроить её в синхронный signup за 200–400 мс и чем она отличается от SMS OTP, reCAPTCHA и тяжёлых KYC-провайдеров.

TL;DR

• $0.005/проверка — на порядок дешевле SMS OTP ($0.04–0.07), на два порядка — KYC-провайдеров типа Onfido/Veriff ($1.5–4)
• Отсев: 8–15% регистраций отсеиваются как виртуалы/одноразовые SIM до того, как съели trial-ресурсы
• Латентность: 250 мс p50, 1.2 с p95 — вписывается в синхронный signup без UX-провала
• Кейсы: SaaS-онбординг, multi-account рефералка, seller verification на маркетплейсе, B2B lead scoring, защита sensitive-действий
• Что не решает: account takeover (нужны device fingerprinting + WebAuthn), реальный бот-трафик (нужен reCAPTCHA Enterprise или Cloudflare Turnstile), новые SIM <14 дней
• Юридически: ст. 6 п. 7 152-ФЗ для RU, legitimate interest по GDPR — согласие не требуется

Почему SaaS — отдельный кейс, не похожий на банки и МФО

Антифрод-литература последних 15 лет писана в основном под банки, МФО и платёжные системы. У них модель угроз простая: ложно одобренная транзакция → прямой денежный убыток. Каскад БКИ + телеком-скоринг + AML — это рациональная архитектура для среды, где одна ошибка стоит $80–800.

У SaaS — другой профиль. Ложно одобренная регистрация почти ничего не стоит в моменте, но кумулятивно бьёт по четырём направлениям сразу:

1. CAC inflation — фейковые регистрации засоряют conversion-метрики, growth-команда таргетится не в ту аудиторию, перформанс-маркетинг увеличивает бюджет
2. Free-tier abuse — GPU-минуты, API-вызовы, бесплатные кредиты съедаются ботнетами и студентами с GitHub Student Pack-ферм
3. Реферальные программы — один человек регистрирует 50 аккаунтов и забирает 50× реферальных бонусов
4. Support cost — 10–20% тикетов в поддержку идут от бесплатных multi-account аккаунтов с типовыми проблемами

Реальные публичные кейсы, которые формируют рынок этой проблемы:

• OpenAI free-tier 2023 — массовый abuse $5 пробных кредитов через одноразовые номера и виртуалки, ужесточение политик до фактического требования платёжного метода при первом запросе (прямое подтверждение OpenAI о борьбе с abuse)
• Plaid trial abuse 2022 — multi-account абьюзеры использовали Plaid Link в dev-режиме для сбора реквизитов с минимальной верификации
• Replicate / Modal / RunPod 2024–2025 — серия инцидентов с криптомайнингом на бесплатных GPU-кредитах через ботнеты регистраций

Везде один паттерн: дешёвая регистрация с одноразовым номером → потребление дорогих инфра-ресурсов на этапе trial → исчезновение до выставления счёта. MAX-проверка ломает первое звено цепи.

Эталонная архитектура: где живёт проверка в signup-флоу

Минимальная архитектура для SaaS среднего размера (10–500k регистраций/мес):

                   ┌─────────────────────────────┐
[Signup Form] ───▶ │   Backend / API Gateway     │
                   └──────────────┬──────────────┘
                                  │
                ┌─────────────────┼──────────────────┐
                ▼                 ▼                  ▼
        [reCAPTCHA v3]    [MAX /check API]    [Email validator]
        score >0.5?       250 ms p50          MX + disposable?
                │                 │                  │
                └─────────────────┼──────────────────┘
                                  ▼
                       ┌────────────────────┐
                       │  Decision engine   │
                       │  (rule + score)    │
                       └─────────┬──────────┘
                                 │
                  ┌──────────────┼──────────────┐
                  ▼              ▼              ▼
            [Allow trial] [Trial limited] [Step-up: SMS OTP]
                                 │
                                 ▼
                         [CRM webhook]
                         phone_verified,
                         risk_score,
                         max_first_name

Три параллельных проверки уходят из бэкенда одновременно (reCAPTCHA, MAX, email). Их результаты собирает decision engine — это может быть простая rule-machine, Stripe Radar-like скоринг, или ML-модель, обученная на исторических лейблах. CRM (HubSpot, Salesforce, Pipedrive) получает webhook с финальным решением и обогащёнными полями.

Ключевой принцип: не делайте MAX-проверку синхронным блокирующим шагом без таймаута. Если /check отвалился по сети — falling back на soft-allow + risk_score += 10, а не отказ пользователю. Подробнее про этот эндпойнт — в гайде по checkAccount-эндпойнту MAX.

Пример интеграции: Node.js / Next.js server action

Минимальный production-ready код для встраивания в Next.js 16 server action или Express-роут. Делает три вещи: вызов с таймаутом, разбор decision-логики, retry на unknown.

// /app/api/signup/route.ts
import { z } from "zod";

const SignupSchema = z.object({
  email: z.string().email(),
  phone: z.string().regex(/^\+[1-9]\d{7,14}$/), // E.164
  recaptchaToken: z.string(),
});

type CheckResult =
  | { status: "registered"; firstName?: string; lastName?: string; lastSeen?: string }
  | { status: "not_found" }
  | { status: "unknown" };

async function checkPhoneInMax(phone: string, signal: AbortSignal): Promise<CheckResult> {
  const res = await fetch(
    `https://api.checkmaxapp.com/v1/check?phone=${encodeURIComponent(phone)}`,
    {
      headers: { Authorization: `Bearer ${process.env.MAX_CHECKER_TOKEN!}` },
      signal,
    }
  );
  if (!res.ok) return { status: "unknown" };
  return (await res.json()) as CheckResult;
}

async function checkWithRetry(phone: string): Promise<CheckResult> {
  for (let attempt = 0; attempt < 2; attempt++) {
    const ctrl = new AbortController();
    const timer = setTimeout(() => ctrl.abort(), 1500); // 1.5s hard budget
    try {
      const r = await checkPhoneInMax(phone, ctrl.signal);
      clearTimeout(timer);
      if (r.status !== "unknown") return r;
    } catch {
      clearTimeout(timer);
    }
    await new Promise((r) => setTimeout(r, 200 * (attempt + 1))); // 200ms, 400ms
  }
  return { status: "unknown" };
}

export async function POST(req: Request) {
  const body = SignupSchema.parse(await req.json());
  const check = await checkWithRetry(body.phone);

  let riskScore = 0;
  if (check.status === "not_found") riskScore += 35;
  if (check.status === "unknown") riskScore += 10;
  if (check.status === "registered" && !check.firstName) riskScore += 5;

  const tier =
    riskScore < 20 ? "full_trial" : riskScore < 50 ? "limited_trial" : "step_up_required";

  return Response.json({ ok: true, tier, riskScore });
}

Этот код намеренно не делает жёсткий отказ — он назначает трек: полный trial, ограниченный trial или step-up верификация (SMS OTP / email). Hard-block на основании одной MAX-проверки — антипаттерн, который похоронит legitimate-конверсию.

Сценарий 1: SaaS-онбординг и защита free-tier

Стандартная воронка B2B SaaS: пользователь оставляет email + телефон + название компании, получает 14-дневный trial или $5 кредитов. Без проверки номера — 8–15% trial-ов уходят на одноразовые виртуалы из SMS-Activate / 5sim / SMS-Man, повторные регистрации после исчерпания лимитов, реферальные накрутки.

Что делает MAX-проверка на этом шаге:

• registered=true + имя есть — full_trial, всё ок
• registered=true, имя пустое — limited_trial, лимиты −50%, мониторинг 7 дней
• not_found — step_up_required, SMS OTP + email verification обязательны
• Повторение not_found + явные multi-account признаки (см. сценарий 2) — soft-block с просьбой написать в support

ROI считается просто. Если abuse одного аккаунта стоит вам $X (GPU-минуты + поддержка + засорение метрик), а MAX-проверка отсекает 50–70% таких аккаунтов до того, как они начали жрать ресурсы, точка безубыточности — несколько долларов в неделю на сотню регистраций. Подробнее про то, почему recall у MAX-проверки близок к 100% и почему это критично для антифрода — в материале про движок 100% recall.

Сценарий 2: пять механик multi-account fraud в SaaS

Multi-account — это не один сценарий, а семейство. Перечисляю пять конкретных механик, с которыми реально сталкиваются Trust&Safety команды:

1. Referral farming. Один человек регистрирует 30–100 аккаунтов с разных виртуалов и забирает реферальные бонусы. Обычно — рекуррентные паттерны: одинаковая User-Agent строка, один IP с прокси-ротацией, имена-вариации одного и того же ФИО.

2. Free-tier hopping. Закончился trial → новый аккаунт с новым номером → продолжение работы. Часто на GPU-провайдерах, AI-API, аналитике. Признак — одинаковый billing email (фантик через +1, +2 или Gmail-dot trick) при разных номерах.

3. Vote / review manipulation. Маркетплейсы, app stores, SaaS-listing-сайты типа Product Hunt: накрутка положительных отзывов через 50 фейковых аккаунтов. Здесь MAX-проверка работает в связке с проверкой имени: если у 50 «пользователей» в MAX совсем другие имена, чем в анкете, — алерт.

4. API key harvesting. Регистрация ради бесплатного API-ключа для дальнейшей перепродажи или интеграции в чужой продукт. Особенно актуально для AI-провайдеров. Признак — мгновенная генерация API-ключа после signup без какой-либо активности в UI.

5. Beta program abuse. Закрытая бета с лимитом инвайтов: один человек регистрирует 10 аккаунтов, забирает 10 инвайтов, перепродаёт их в Telegram-каналах. MAX-проверка по имени из публичного профиля + кластеризация по server ID отлавливает значительную часть.

Во всех пяти случаях MAX-проверка — не серебряная пуля, а слабый сигнал в связке с другими: IP reputation, device fingerprinting (FingerprintJS, ThreatMetrix), behavioral analytics. См. также OWASP Automated Threats — стандартный таксономический справочник по этим атакам.

Сценарий 3: маркетплейсы и двусторонние платформы

Двусторонний маркетплейс (фриланс-биржа, P2P-аренда, classified-доска объявлений, B2B-каталог поставщиков) уязвим с двух сторон. На стороне покупателя — стандартный SaaS-онбординг. На стороне продавца — гораздо опаснее: продавец-однодневка собирает предоплаты и исчезает.

Связка проверок при seller onboarding:

• MAX-проверка → имя в публичном профиле должно соответствовать заявленному (хотя бы фамилия)
• Last seen из публичного профиля → активный аккаунт, а не свежий «однодневный»
• Bio-поле из MAX → доп. контекст: упоминание профессии, города, компании

Если у продавца, заявившего себя как «ИП Иванов И.И.», в MAX-профиле имя «Дмитрий» и last seen двухмесячной давности — это не блок, но это требование дополнительной верификации перед публикацией первых лотов. Stripe в Radar-документации описывает такой паттерн как additional_verification rule action — и это правильный шаблон.

Сценарий 4: B2B lead scoring без burning CAC

CRM получает лидов из 10 каналов: формы, чаты, парсинг ВКонтакте, выгрузки из конференций. Качество разное, отдел продаж жжёт время на «номер не отвечает».

Связка: лид → нормализация в E.164 → MAX-проверка → enrichment в CRM:

1. Webhook из формы → backend
2. Нормализация в E.164 (libphonenumber)
3. MAX-проверка → registered/not_found/unknown + имя
4. Запись в CRM: phone_verified, phone_check_at, phone_first_name, phone_last_seen
5. Менеджер фильтрует по phone_verified == true и сортирует по last_seen по убыванию

ROI считается через сэкономленные минуты SDR. На дашборде HubSpot/Pipedrive/Bitrix24 можно вытащить time_to_first_call и call_connect_rate до и после внедрения — у клиентов мы видели улучшение connect-rate на 25–40% за счёт того, что менеджеры не звонят на мёртвые номера.

Сценарий 5: защита sensitive-действий, не только signup

MAX-проверка полезна не только в момент регистрации. Чувствительные действия в LTV-цикле клиента:

• Смена email на учётной записи
• Запрос вывода реферальных бонусов / партнёрских выплат
• Изменение биллингового метода
• Экспорт большой партии данных
• Запрос refund

В этих точках имеет смысл повторно проверить актуальное состояние номера: если за 60 дней с момента regista номер unregistered или сменил имя в публичном профиле — это сигнал к step-up верификации. Триггер для алерта security: phone_status_changed_post_signup.

Latency budget: где теряются миллисекунды в синхронном antifraud

Для синхронного antifraud-флоу в signup критичен полный budget «от submit до response». Типичный breakdown:

Главный вывод: запускайте все внешние проверки параллельно через Promise.all (или эквивалент в вашем стеке). MAX, reCAPTCHA и IP reputation — это независимые сетевые вызовы, нет причин делать их последовательно. Decision engine ждёт Promise.allSettled и собирает score.

Второй вывод: если синхронный budget жёсткий (например, UX-требование «signup за 1 сек p95»), MAX-проверка делается асинхронно — пользователь сразу получает limited-trial, а через 1–2 секунды в фоне приходит результат, который либо апгрейдит до full-trial, либо назначает step-up верификацию при следующем входе.

Сравнение: MAX-проверка vs SMS OTP vs email vs KYC-провайдер

MAX-проверка занимает специфическую нишу: нулевой friction + копеечная цена + сильный сигнал о существовании реального профиля. SMS OTP подтверждает другое — что в моменте signup кто-то получил SMS. Эти два метода дополняют, а не заменяют друг друга. Лучшая архитектура — каскад MAX → (если risk_score высок) → SMS OTP → (если flow требует) → полный KYC.

Что вы НЕ сможете решить через MAX-проверку

Честная граница применимости:

1. Account takeover (ATO) — credential stuffing, фишинг, session hijacking. Здесь работают device fingerprinting, anomaly detection в логах входов, WebAuthn / passkeys. MAX-проверка применима только при чувствительных действиях после успешного логина, не как защита логина сам по себе.
2. Реальный bot-трафик — массовые регистрации через headless-браузеры. Нужны reCAPTCHA Enterprise или Cloudflare Turnstile, которые анализируют поведенческие сигналы и фингерпринт.
3. Свежие SIM-карты <14 дней часто ещё не подняли профиль в MAX. Это not_found без вины пользователя — не используйте как hard-block.
4. Полная анонимность профиля. Около 5–8% пользователей сознательно скрывают имя и last seen. Это нормально, не сигнал фрода сам по себе.
5. Доказательства в суде. Публичный профиль в мессенджере не является криминалистическим доказательством — это сигнал для бизнес-решения, не для иска.
6. Корпоративные / виртуальные номера (АТС, virtual numbers Twilio) почти никогда не зарегистрированы в MAX. Для B2B-онбординга это означает: разрешите альтернативный канал верификации для пользователей, которые звонят с корпоративного номера.
7. Behavioral / интенциональные фроды. Реальный человек с реальным номером, который сознательно abuse-ит trial — MAX-проверка его не остановит. Здесь нужны behavioral analytics, rate limiting, abuse detection в логах использования продукта.

Эту границу важно проговорить честно перед руководством, чтобы не было ожидания «купили MAX-чекер — закрыли антифрод». MAX-проверка — это один слой каскада, не весь каскад.

Юридические аспекты для B2B SaaS

Для российских пользователей применима ст. 6 п. 7 152-ФЗ: «противодействие мошенничеству» как законная цель обработки ПДн без отдельного согласия. Условия:

• цель «противодействие мошенничеству» включена в политику обработки ПДн
• пользователь уведомлён в privacy notice, что номер может быть проверен по открытым источникам
• результат проверки хранится не дольше срока, обусловленного целью

Для GDPR (если у вас есть пользователи из ЕС) применимо legitimate interest по Art. 6(1)(f) — с проведённым LIA (Legitimate Interest Assessment) и упоминанием в privacy notice. См. также ENISA Threat Landscape — европейский справочник по угрозам, где fraud prevention указан как стандартная legitimate-цель.

Для CCPA (Калифорния) — аналогично, business purpose (анти-фрод) не требует opt-out при корректном disclosure.

Что в любой юрисдикции делать нельзя:

• Использовать результат MAX-проверки как единственное основание отказа в услуге без объяснения причины
• Передавать MAX-обогащённые поля (firstName, lastSeen) третьим лицам без отдельного согласия
• Использовать last seen для прицельного маркетинга без opt-in

Как подключить

1. Через бот — для пилота на 1000–10 000 регистраций: CSV-выгрузка из CRM, проверка батчем, обратная загрузка в HubSpot/Salesforce
2. Через API — для production-pipeline. Sync /check эндпойнт, p95 1.5 с, документация в гайде по REST-эндпойнту
3. Тарификация — стандарт $0.005, на объёме от $2000/мес — тариф $0.003 (см. цены)

После пилота — расчёт эффективной цены под ваш объём и подключение через индивидуальный API-токен.

Полезные ссылки

• Как работает Max Checker — техническая страница про recall и архитектуру
• REST-эндпойнт /checkAccount — параметры запроса, формат ответа
• Антифрод-кейсы в продукте — отдельная страница use-case’ов
• Движок 100% recall — почему recall важен для антифрод-логики
• 152-ФЗ и проверка номеров — юридический разбор
• OWASP Automated Threats — внешний справочник по фрод-таксономии
• Stripe Radar rules reference — пример design pattern для rule engine
• Cloudflare Turnstile docs — комплементарная защита от ботов

Об авторе

Команда Max Checker работает с антифрод-задачами для B2B SaaS с 2024 года. Запускали интеграции в HubSpot, Pipedrive, AmoCRM и кастомных Node.js / Python бэкендах. Кейсы охватывают AI-API провайдеров, маркетплейсы услуг, fintech-онбординг и реферальные программы. Если у вас специфичный сценарий — напишите через бот поддержки, разберём бесплатно.