Разработка системы лимитов и верификации крипто-обменника

Почему система лимитов обменника даёт сбои на пике нагрузки

Система лимитов обменника в норме — один источник правды: пороги по клиенту, каналу приёма и операции, счётчик в транзакционном хранилище и проверка перед подтверждением заявки. Ломается она не на значениях порогов, а на согласованности: как только заявки идут из нескольких точек и обрабатываются параллельно, счётчики расходятся, и операции проходят выше порога.

Учёт лимитов по каналам чаще ведут раздельно: сайт, партнёрские интеграции и терминал оператора пишут в свои таблицы, а сводка собирается по расписанию с задержкой в минуты. Клиент за это время отправляет вторую заявку — проверка видит старое значение и пропускает обе. Параллельные заявки одного клиента дают тот же эффект и в одном хранилище: чтение и запись не сериализуются, две операции читают одинаковый остаток и обе его списывают.

Отдельный источник расхождений — ручные правки в панели оператора: снятие блокировки или повышение порога применяют к профилю, но не к накопленному счётчику и без записи в аудит-лог. Дальше растут спорные операции обменника: клиент оспаривает отказ, а восстановить фактическую картину по журналам уже нельзя. Расхождение в пару процентов заявок за сутки — это часы ручного разбора и потерянные обращения.

Требования к порогам и проверке источника средств задают рекомендации FATF, но согласованность счётчиков остаётся инженерной задачей. Разбираем, как это закрывается: резервированием лимита на время обработки, идемпотентными заявками и аудитом, по которому состояние восстанавливается на любой момент.

Что даёт автоматический контроль лимитов и уровней верификации

Правила лимитов живут в ядре, а не в каждом канале. Уровни верификации клиента превращаются в набор порогов: суммарный объём за период, число операций, доступные направления обмена. Автоматический контроль лимитов считает накопление из единого журнала, поэтому переход между веб-кабинетом, мобильным приложением и программным интерфейсом не сбрасывает остаток — единый счётчик по каналам всегда один и тот же.

Каждая операция получает ключ идемпотентности, а начисление — ссылку на исходное событие. Повторная отправка запроса на стороне клиента или дубль от платёжного провайдера не создают второе зачисление: система видит уже применённое событие и возвращает прежний результат. Так уходит целый класс отказов — «двойное зачисление» перестаёт быть инцидентом и становится невозможным по конструкции.

Время разбора спорной операции определяется тем, что журнал хранит снимок правил, действовавших в момент её проведения. Проверяющий видит, какой уровень верификации клиента был активен, какой порог применялся и почему операция прошла или была остановлена, — без восстановления контекста по логам разных сервисов.

• Ручные разборы. Доля операций, которые сотрудник открывает вручную, падает за счёт автоматической остановки на пороге и понятной причины отказа в интерфейсе.
• Спорные операции. Разбор идёт по снимку правил, а не по переписке с поддержкой: типовой кейс закрывается за минуты вместо часов поиска по логам.
• Сверка каналов. Расхождения между кабинетом, приложением и программным интерфейсом исчезают: источник накопления один.

Уровни верификации клиента обновляются автоматически по данным провайдера — при интеграции с Sumsub смена статуса сразу меняет пороги, без ручной правки в учётной системе. Понижение уровня ужесточает лимиты мгновенно, повышение открывает новые направления обмена.

Способы ведения учёта: сравнение подходов и ограничений

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

Выбор подхода определяет две вещи: как быстро вы поменяете правило и чем докажете его исполнение при разборе. Ниже — варианты, между которыми реально выбирают на внедрении.

На практике чаще выбирают последний вариант: внешний поставщик проверки клиентов закрывает базовую идентификацию, а выделённый сервис учёта лимитов держит журнал операций обменника и накладывает правила поверх результата проверки. Сверка становится ежедневной процедурой, а расхождение — поводом отклонить операцию, а не разбираться постфактум.

Этапы работ: от разбора потоков заявок до передачи регламентов

Каждый этап заканчивается артефактом, который можно проверить: картой потоков, таблицей порогов, схемой хранения, набором тестов. Так внедрение системы лимитов не растягивается на месяцы и не превращается в правки «на глаз» после первых инцидентов.

1. Аудит потоков заявок. Снимаем карту движения заявки: какие каналы, какие поля приходят, где решение принимает человек, где автоматика. Отдельно фиксируем точки, где лимит проверяется сейчас, и места, где проверка обходится — например, при повторной отправке или смене способа оплаты.
2. Модель порогов. Раскладываем лимиты по осям: уровень верификации клиента, сумма и частота операций, способ оплаты, регион и устройство. Для каждого порога описываем владельца, поведение при превышении и условие сброса.
3. Схема хранения состояния. Счётчики за окно, история статусов клиента, ключи, защищающие от двойного списания лимита, журнал решений — по нему потом видно, почему заявка прошла автоматически или ушла на ручной разбор.
4. Настройка проверок клиента. Привязываем уровни верификации к порогам, задаём правила эскалации и разбор в ручной очереди со сроком реакции. Пороги меняются конфигурацией, а не релизом кода.
5. Прогон на отказах. Проверяем не только happy path: превышение, параллельные заявки, повторная отправка, недоступность внешнего сервиса, откат статуса. Цель — лимит не «залипает» и не обходится при сбое.
6. Передача и обучение поддержки. Отдаём регламенты, дерево решений и дашборд с долей автоматических отказов и ручных разборов, проводим обучение смены.

После передачи изменения порогов остаются управляемыми: поведение предсказуемо, а решения по лимитам воспроизводимы.

Состав поставки: конфигурации, схемы, регламенты, документация

Поставка закрывается не запуском, а тем, что остаётся в руках команды заказчика после передачи. Ниже — комплект, с которым можно менять правила, разбирать спорные операции и вводить новых операторов без нас.

• Конфигурации лимитов в виде репозитория правил: уровни по верификации, суточные и месячные пороги на клиента, пару валют, способ оплаты, страну и историю поведения. Каждое изменение — отдельная ревизия с автором, обоснованием и возможностью отката на предыдущую версию.
• Схемы потоков заявок: от приёма до финального статуса, включая ветки ручной проверки, тайм-ауты ожидания и точки, где заявка автоматически уходит на разбор. На схемах отмечены места вызова лимитов и проверок адресов.
• Матрица прав доступа операторов: роль, какие операции доступны, какие поля видны, что требует второго подтверждения. Отдельно — разграничение между сменами и уровни эскалации.
• Регламент разбора операций: пошаговый порядок для сработавшего лимита, расхождения статусов и обращения клиента по зависшей заявке. С фиксацией решения, причины и ссылкой на правило, которое сработало.
• Документация по лимитам: назначение каждого параметра, что он меняет в поведении системы, какие значения считаются рабочими, а какие требуют согласования.
• Инструкции для операторов — короткие сценарии на каждый частый случай: как поднять порог в рамках полномочий, как оформить ручную проверку, что делать при подозрении на дробление сумм.
• Журнал изменений и доступов: кто и когда правил правило, кто смотрел данные клиента, кто подтверждал ручную операцию.
• План передачи: разбор комплекта с командой заказчика, прогон типовых сценариев на стенде, контрольные точки на самостоятельное изменение лимита и разбор операции.

Такой набор снимает главный риск — что правила живут в голове подрядчика. Опишите вашу задачу: соберём перечень под ваш контур и вернёмся с оценкой и планом передачи.

Кейс: как обменник убрал двойные зачисления на пике

Обменник на пике держал лимиты одним полем: код читал остаток, проверял его и записывал новое значение. Между чтением и записью успевала проскочить вторая заявка того же клиента — обе проходили проверку, и вторая зачислялась по уже исчерпанному лимиту. Расхождение находили на сверке, то есть через часы после операции.

До правок доля отказов из-за одновременных заявок держалась около 4% от суточного объёма, оператор за смену вручную закрывал больше тридцати расхождений, а спорная операция висела до нескольких часов. Пиковая нагрузка заявок только усиливала эффект.

Лимит перестал быть полем в таблице и стал отдельной записью-резервом. Транзакция берёт строку под блокировку, проверяет остаток и списывает его до обращения к внешнему сервису — окно гонки закрывается на уровне хранилища, а не на уровне кода обработчика. Заявка приходит с ключом идемпотентности: повтор не создаёт второй резерв, а возвращает результат первого. Отмена не удаляет запись, а добавляет компенсирующую — история операций остаётся проверяемой.

Хранилище собрали на PostgreSQL: уникальный индекс по ключу заявки плюс блокировка строки резерва. Ручные корректировки остались только для возвратов по внешним причинам.

Метрики до и после: доля отказов из-за одновременных заявок — 4% против 0,1%, ручные корректировки за смену — 34 против 2, время закрытия спорной операции — часы против 10 минут. Пиковая нагрузка заявок при этом выросла втрое — очередей и повторных зачислений не появилось.

Чем верификация по документам отличается от поведенческой?

Проверка по документам отвечает на вопрос «кто этот человек»: сверяет документ с селфи, отсекает подделку, проверяет возраст и санкционные списки. Результат детерминированный — на выходе остаётся юридически значимый след. Но документ описывает состояние на входе и ничего не говорит о том, как клиент поведёт себя дальше.

Поведенческая верификация смотрит на действия: скорость операций, дробление суммы вокруг порогов лимита, число связанных адресов, повторяющиеся связки «устройство — сеть» у разных аккаунтов. Она ловит сеть подставных лиц с настоящими паспортами — то, чего документ не покажет. Плата за это — чувствительность к контексту: корпоративный VPN даёт тот же сигнал, что и попытка обхода.

Здесь и появляются ложные срабатывания проверок. Правило «часто меняет адрес вывода» без калибровки по историческим данным помечает активного трейдера так же, как того, кто дробит лимиты. Если поведенческий слой работает жёсткой блокировкой, заметная доля срабатываний приходится на добросовестных клиентов — это потерянный оборот и нагрузка на поддержку.

Поэтому уровни разделяют по роли. Документы — базовый слой: без пройденной проверки лимит нулевой. Поведение — надстройка, которая не блокирует, а управляет порогами: повышенный риск снижает суточный лимит и уводит операцию на ручной разбор. Автоблокировка включается только при совпадении двух независимых сигналов — например, расхождения в документе и связки с уже закрытым аккаунтом.

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

Частые технические вопросы по учёту операций и проверкам

Сомнения по системе лимитов и учёту операций возникают не на проектировании, а на стыке с эксплуатацией: правила меняются на ходу, у одного клиента появляется второй канал, внешняя проверка отвечает с задержкой. Ниже — как эти случаи закрыты в конфигурации.

У клиента несколько каналов — лимиты считаются вместе?

Счётчик общий на клиента, а не на канал: признаки связываются в один профиль, поэтому обойти порог через второй канал нельзя. Пороги задаются на уровне клиента, канала или их пары — что считать одним клиентом, определяется на этапе настройки.

Можно ли подключить внешнюю проверку клиента?

Да, сторонний сервис проверки встраивается отдельным шагом и работает асинхронно. При его недоступности заявка уходит на ручной разбор, а не в автоодобрение, а результат проверки сохраняется вместе с версией правил, по которым принималось решение.

Как проходит приёмка перед запуском?

Прогоняем сценарии на тестовом контуре: граничные суммы, повторные заявки, смена правил при открытой заявке, отказ внешнего сервиса. Приёмка пройдена, когда журнал решений по каждой заявке воспроизводится и совпадает с ожидаемым.

Обсудим задачу: разберём ваши потоки и вернёмся с оценкой

Чтобы обсудить задачу внедрения предметно, а не по общим шаблонам, нам нужен срез вашей текущей конфигурации: как заявки попадают в систему, где считаются лимиты и что сейчас решает человек. Без этого оценка сроков будет гаданием — считаем по вашим данным, а не по средним.

• Перечень каналов приёма заявок — API, веб-форма, бот, заявки от менеджеров: по каждому важно, где считается лимит и как передаётся идентификатор клиента.
• Текущие правила порогов — по какому признаку режется объём: сумма за период, число операций, уровень верификации, страна, метод оплаты; отдельно — где правила конфликтуют.
• Точки ручного вмешательства — какие решения принимает оператор, по какой причине и что происходит, когда его нет на смене.
• Спорные сценарии — дробление суммы на несколько операций, смена реквизитов, связанные аккаунты: чаще всего именно они ломают автоматику.
• Приоритеты по нагрузке — пиковая частота проверок, допустимая задержка отклика и доля операций, которые должны проходить без человека.
• Доступы и ограничения — тестовый контур, песочница провайдера, требования по хранению логов проверок.

С этим набором мы возвращаемся с оценкой и планом работ: схема проверок, очередь задач по приоритету, точки контроля и порядок выката без остановки обмена. Если часть данных закрыта — опишите словами, этого хватит для первой версии архитектуры.