Чому система лімітів обмінника дає збої на піку навантаження
Система лімітів обмінника в нормі — одне джерело правди: пороги за клієнтом, каналом прийому й операцією, лічильник у транзакційному сховищі та перевірка перед підтвердженням заявки.
Ламається вона не на значеннях порогів, а на узгодженості: щойно заявки надходять із кількох точок і обробляються паралельно, лічильники розходяться, і операції проходять вище порога.
Облік лімітів за каналами частіше ведуть окремо: сайт, партнерські інтеграції та термінал оператора пишуть у свої таблиці, а зведення збирається за розкладом із затримкою в хвилини. Клієнт за цей час надсилає другу заявку — перевірка бачить старе значення й пропускає обидві.
Паралельні заявки одного клієнта дають той самий ефект і в одному сховищі: читання й запис не серіалізуються, дві операції читають однаковий залишок і обидві його списують.
Окреме джерело розбіжностей — ручні правки в панелі оператора: зняття блокування або підвищення порога застосовують до профілю, але не до накопиченого лічильника й без запису в аудит-лог.
Далі зростають спірні операції обмінника: клієнт оскаржує відмову, а відновити фактичну картину за журналами вже неможливо. Розбіжність у пару відсотків заявок за добу — це години ручного розбору й втрачені звернення.
Вимоги до порогів і перевірки джерела коштів задають рекомендації FATF, але узгодженість лічильників залишається інженерною задачею.
Розбираємо, як це закривається: резервуванням ліміту на час обробки, ідемпотентними заявками й аудитом, за яким стан відновлюється на будь-який момент.
Що дає автоматичний контроль лімітів і рівнів верифікації
Правила лімітів живуть у ядрі, а не в кожному каналі. Рівні верифікації клієнта перетворюються на набір порогів: сумарний обсяг за період, кількість операцій, доступні напрями обміну.
Автоматичний контроль лімітів рахує накопичення з єдиного журналу, тому перехід між вебкабінетом, мобільним застосунком і програмним інтерфейсом не скидає залишок — єдиний лічильник за каналами завжди той самий.
Кожна операція отримує ключ ідемпотентності, а нарахування — посилання на вихідну подію. Повторне надсилання запиту на боці клієнта або дубль від платіжного провайдера не створюють друге зарахування: система бачить уже застосовану подію й повертає попередній результат.
Так зникає цілий клас відмов — «подвійне зарахування» перестає бути інцидентом і стає неможливим за конструкцією.
Час розбору спірної операції визначається тим, що журнал зберігає знімок правил, чинних на момент її проведення.
Перевіряльник бачить, який рівень верифікації клієнта був активний, який поріг застосовувався й чому операція пройшла або була зупинена, — без відновлення контексту за логами різних сервісів.
- Ручні розбори. Частка операцій, які співробітник відкриває вручну, падає завдяки автоматичній зупинці на порозі та зрозумілій причині відмови в інтерфейсі.
- Спірні операції. Розбір іде за знімком правил, а не за листуванням із підтримкою: типовий кейс закривається за хвилини замість годин пошуку за логами.
- Звірка каналів. Розбіжності між кабінетом, застосунком і програмним інтерфейсом зникають: джерело накопичення одне.
Рівні верифікації клієнта оновлюються автоматично за даними провайдера — за інтеграції з Sumsub зміна статусу одразу змінює пороги, без ручної правки в обліковій системі. Пониження рівня миттєво посилює ліміти, підвищення відкриває нові напрями обміну.
Способи ведення обліку: порівняння підходів і обмежень
Облік лімітів рідко виносять в окремий компонент на старті — спочатку правила живуть у панелі оператора або всередині самого сервісу обміну.
Розбіжність спливає пізніше: паралельні угоди рахують залишок за різними знімками даних, а відновити картину нічим — історія змін ніде не фіксується.
Вибір підходу визначає дві речі: як швидко ви зміните правило й чим доведете його виконання під час розбору. Нижче — варіанти, між якими реально обирають на впровадженні.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручні правила в панелі | Мало операторів, малий потік, правила змінюються рідко | Правки не версіонуються, за одночасних операцій залишок розходиться, немає історії рішень |
| Ліміти всередині сервісу обміну | Один канал входу, ліміти прості та статичні | Логіка обліку змішана з розрахунками угод: зміна правила вимагає викату обмінника, частину сценаріїв не покрити |
| Виділений сервіс обліку лімітів із журналом операцій | Кілька каналів, правила залежать від рівня клієнта й валюти | Окремий контур, міграція накопичених лічильників, потрібна звірка з джерелом угод |
| Зовнішній постачальник перевірки клієнтів | Потрібна швидка базова ідентифікація без власної експертизи | Регламент постачальника не покриває внутрішні ліміти, дані йдуть на сторону, зв'язок з обліком слабкий |
| Гібридна схема верифікації | Потрібні і зовнішня перевірка, і власні правила поверх неї | Складніше в налагодженні: два джерела вимагають регулярної звірки |
На практиці частіше обирають останній варіант: зовнішній постачальник перевірки клієнтів закриває базову ідентифікацію, а виділений сервіс обліку лімітів веде журнал операцій обмінника й накладає правила поверх результату перевірки.
Звірка стає щоденною процедурою, а розбіжність — приводом відхилити операцію, а не розбиратися постфактум.
Етапи робіт: від розбору потоків заявок до передачі регламентів
Кожен етап закінчується артефактом, який можна перевірити: картою потоків, таблицею порогів, схемою зберігання, набором тестів. Так впровадження системи лімітів не розтягується на місяці й не перетворюється на правки «на око» після перших інцидентів.
- Аудит потоків заявок. Знімаємо карту руху заявки: які канали, які поля надходять, де рішення ухвалює людина, де автоматика. Окремо фіксуємо точки, де ліміт перевіряється зараз, і місця, де перевірка обходиться — наприклад, під час повторного надсилання або зміни способу оплати.
- Модель порогів. Розкладаємо ліміти за осями: рівень верифікації клієнта, сума й частота операцій, спосіб оплати, регіон і пристрій. Для кожного порога описуємо власника, поведінку при перевищенні та умову скидання.
- Схема зберігання стану. Лічильники за вікно, історія статусів клієнта, ключі, що захищають від подвійного списання ліміту, журнал рішень — за ним потім видно, чому заявка пройшла автоматично або пішла на ручний розбір.
- Налаштування перевірок клієнта. Прив'язуємо рівні верифікації до порогів, задаємо правила ескалації та розбір у ручній черзі зі строком реакції. Пороги змінюються конфігурацією, а не релізом коду.
- Прогін на відмовах. Перевіряємо не лише happy path: перевищення, паралельні заявки, повторне надсилання, недоступність зовнішнього сервісу, відкат статусу. Мета — ліміт не «залипає» й не обходиться під час збою.
- Передача й навчання підтримки. Віддаємо регламенти, дерево рішень і дашборд із часткою автоматичних відмов і ручних розборів, проводимо навчання зміни.
Після передачі зміни порогів залишаються керованими: поведінка передбачувана, а рішення щодо лімітів відтворювані.
Склад постачання: конфігурації, схеми, регламенти, документація
Постачання закривається не запуском, а тим, що залишається в руках команди замовника після передачі. Нижче — комплект, із яким можна змінювати правила, розбирати спірні операції та вводити нових операторів без нас.
- Конфігурації лімітів у вигляді репозиторію правил: рівні за верифікацією, добові та місячні пороги на клієнта, пару валют, спосіб оплати, країну та історію поведінки. Кожна зміна — окрема ревізія з автором, обґрунтуванням і можливістю відкату на попередню версію.
- Схеми потоків заявок: від прийому до фінального статусу, включно з гілками ручної перевірки, тайм-аутами очікування та точками, де заявка автоматично йде на розбір. На схемах позначені місця виклику лімітів і перевірок адрес.
- Матриця прав доступу операторів: роль, які операції доступні, які поля видно, що потребує другого підтвердження. Окремо — розмежування між змінами та рівні ескалації.
- Регламент розбору операцій: покроковий порядок для спрацьованого ліміту, розбіжності статусів і звернення клієнта щодо завислої заявки. Із фіксацією рішення, причини та посиланням на правило, яке спрацювало.
- Документація з лімітів: призначення кожного параметра, що він змінює в поведінці системи, які значення вважаються робочими, а які потребують узгодження.
- Інструкції для операторів — короткі сценарії на кожен частий випадок: як підняти поріг у межах повноважень, як оформити ручну перевірку, що робити за підозри на дроблення сум.
- Журнал змін і доступів: хто й коли правил правило, хто дивився дані клієнта, хто підтверджував ручну операцію.
- План передачі: розбір комплекту з командою замовника, прогін типових сценаріїв на стенді, контрольні точки на самостійну зміну ліміту й розбір операції.
Такий набір знімає головний ризик — що правила живуть у голові підрядника. Опишіть вашу задачу: зберемо перелік під ваш контур і повернемося з оцінкою та планом передачі.
Кейс: як обмінник прибрав подвійні зарахування на піку
Обмінник на піку тримав ліміти одним полем: код читав залишок, перевіряв його й записував нове значення. Між читанням і записом встигала проскочити друга заявка того самого клієнта — обидві проходили перевірку, і друга зараховувалася за вже вичерпаним лімітом. Розбіжність знаходили на звірці, тобто через години після операції.
До правок частка відмов через одночасні заявки трималася близько 4% від добового обсягу, оператор за зміну вручну закривав понад тридцять розбіжностей, а спірна операція висіла до кількох годин. Пікове навантаження заявок лише підсилювало ефект.
Ліміт перестав бути полем у таблиці й став окремим записом-резервом. Транзакція бере рядок під блокування, перевіряє залишок і списує його до звернення до зовнішнього сервісу — вікно гонки закривається на рівні сховища, а не на рівні коду обробника.
Заявка надходить із ключем ідемпотентності: повтор не створює другий резерв, а повертає результат першого. Скасування не видаляє запис, а додає компенсаційний — історія операцій залишається перевірюваною.
Сховище зібрали на PostgreSQL: унікальний індекс за ключем заявки плюс блокування рядка резерву. Ручні коригування залишилися лише для повернень із зовнішніх причин.
Метрики до й після: частка відмов через одночасні заявки — 4% проти 0,1%, ручні коригування за зміну — 34 проти 2, час закриття спірної операції — години проти 10 хвилин. Пікове навантаження заявок при цьому зросло втричі — черг і повторних зарахувань не з'явилося.
Чим верифікація за документами відрізняється від поведінкової?
Перевірка за документами відповідає на питання «хто ця людина»: звіряє документ із селфі, відсікає підробку, перевіряє вік і санкційні списки. Результат детермінований — на виході залишається юридично значущий слід. Але документ описує стан на вході й нічого не говорить про те, як клієнт поводитиметься далі.
Поведінкова верифікація дивиться на дії: швидкість операцій, дроблення суми навколо порогів ліміту, кількість пов'язаних адрес, повторювані зв'язки «пристрій — мережа» в різних акаунтів. Вона ловить мережу підставних осіб із справжніми паспортами — те, чого документ не покаже. Плата за це — чутливість до контексту: корпоративний VPN дає той самий сигнал, що й спроба обходу.
Тут і з'являються хибні спрацювання перевірок. Правило «часто змінює адресу виведення» без калібрування за історичними даними позначає активного трейдера так само, як того, хто дробить ліміти.
Якщо поведінковий шар працює жорстким блокуванням, помітна частка спрацювань припадає на добросовісних клієнтів — це втрачений оборот і навантаження на підтримку.
Тому рівні розділяють за роллю. Документи — базовий шар: без пройденої перевірки ліміт нульовий. Поведінка — надбудова, яка не блокує, а керує порогами: підвищений ризик знижує добовий ліміт і відводить операцію на ручний розбір.
Автоблокування вмикається лише за збігу двох незалежних сигналів — наприклад, розбіжності в документі та зв'язки з уже закритим акаунтом.
Поріг для зовнішніх сервісів налаштовується окремо: Sumsub та аналоги повертають оцінку ризику, і ми прив'язуємо її до рівнів лімітів, а не до відповіді «так чи ні». Добросовісний клієнт проходить перевірку за хвилини, а увага аналітика дістається реальним перетинам.
Часті технічні питання щодо обліку операцій і перевірок
Сумніви щодо системи лімітів і обліку операцій виникають не на проєктуванні, а на стику з експлуатацією: правила змінюються на ходу, в одного клієнта з'являється другий канал, зовнішня перевірка відповідає із затримкою. Нижче — як ці випадки закриті в конфігурації.
Що буде, якщо правила зміняться за відкритих заявок?
Кожна заявка посилається на версію правил, чинну на момент її створення. Нові умови застосовуються до нових заявок, а вже відкриті доводяться за попередньою редакцією — перерахунку заднім числом немає, і в журналі видно, за якою версією ухвалено рішення.
У клієнта кілька каналів — ліміти рахуються разом?
Лічильник спільний на клієнта, а не на канал: ознаки зв'язуються в один профіль, тому обійти поріг через другий канал не можна. Пороги задаються на рівні клієнта, каналу або їхньої пари — що вважати одним клієнтом, визначається на етапі налаштування.
Чи можна підключити зовнішню перевірку клієнта?
Так, сторонній сервіс перевірки вбудовується окремим кроком і працює асинхронно. За його недоступності заявка йде на ручний розбір, а не в автосхвалення, а результат перевірки зберігається разом із версією правил, за якими ухвалювалося рішення.
Як проходить приймання перед запуском?
Проганяємо сценарії на тестовому контурі: граничні суми, повторні заявки, зміна правил за відкритої заявки, відмова зовнішнього сервісу. Приймання пройдено, коли журнал рішень щодо кожної заявки відтворюється й збігається з очікуваним.
Обговоримо задачу: розберемо ваші потоки й повернемося з оцінкою
Щоб обговорити задачу впровадження предметно, а не за загальними шаблонами, нам потрібен зріз вашої поточної конфігурації: як заявки потрапляють у систему, де рахуються ліміти й що зараз вирішує людина. Без цього оцінка строків буде ворожінням — рахуємо за вашими даними, а не за середніми.
- Перелік каналів прийому заявок — API, вебформа, бот, заявки від менеджерів: для кожного важливо, де рахується ліміт і як передається ідентифікатор клієнта.
- Поточні правила порогів — за якою ознакою ріжеться обсяг: сума за період, кількість операцій, рівень верифікації, країна, метод оплати; окремо — де правила конфліктують.
- Точки ручного втручання — які рішення ухвалює оператор, з якої причини й що відбувається, коли його немає на зміні.
- Спірні сценарії — дроблення суми на кілька операцій, зміна реквізитів, пов'язані акаунти: найчастіше саме вони ламають автоматику.
- Пріоритети за навантаженням — пікова частота перевірок, допустима затримка відгуку й частка операцій, які мають проходити без людини.
- Доступи й обмеження — тестовий контур, пісочниця провайдера, вимоги щодо зберігання логів перевірок.
Із цим набором ми повертаємося з оцінкою та планом робіт: схема перевірок, черга задач за пріоритетом, точки контролю й порядок викату без зупинки обміну. Якщо частина даних закрита — опишіть словами, цього вистачить для першої версії архітектури.
