Финтех в ПВТ: биллинг и анти-казино фильтры без ошибок

ПВТ многие до сих пор воспринимают как магическую кнопку: получил статус резидента — и дальше можно спокойно оплачивать зарубежные серверы, API и SaaS-подписки без лишних вопросов. На практике я вижу другую картину. Льгота работает, но финтех-продукту этого мало. Если в биллинге нет нормальной структуры расходов, если платёж в Stripe Atlas, AWS или OpenAI проходит как “что-то там за облако”, если нет внятной трассировки от инвойса до проекта, у тебя появляется не техническая, а управленческая дыра. А с 11 марта 2026 года добавился ещё один слой реальности: в Беларуси вступили в силу новые правила по игорному бизнесу, и платежные сценарии, связанные с иностранными онлайн-казино, стали жёстко ограничиваться на уровне самих операций по картам.

Где здесь реальная выгода ПВТ

У резидентов ПВТ действительно есть льгота по оффшорному сбору. Это прямо перечислено и на официальной странице ПВТ о преимуществах и льготах, и на странице Министерства экономики о ПВТ. Основа режима — Декрет №8 «О развитии цифровой экономики», который вообще сделал ПВТ не просто льготной площадкой, а отдельной инженерной средой для продуктовых и сервисных IT-команд.

Но тут есть важный практический момент. Сам факт льготы не превращает любой зарубежный расход в “безопасный по умолчанию”. Я бы не строил продукт так, будто бухгалтерия всё потом разберёт руками. В реальной компании именно биллинг-слой должен быстро отвечать на простые вопросы:

• за что именно ушли деньги;
• к какому продукту, клиенту или внутреннему сервису относится расход;
• кто санкционировал покупку;
• какой договор, инвойс или подписка лежит под этой операцией;
• почему этот расход вообще логичен для деятельности компании.

Если ответ на любой из этих пунктов ищется по письмам, PDF и скриншотам из банка, значит у тебя не биллинг, а архив хаоса.

Как я бы строил биллинг для зарубежной инфраструктуры

Когда продукт живёт на зарубежной инфраструктуре, я почти всегда разделяю расходы минимум на четыре слоя: compute, data, communication и external tooling.

Примерно так:

• compute: AWS, Google Cloud, DigitalOcean, Hetzner;
• data: managed PostgreSQL, S3-compatible storage, vector DB, backup providers;
• communication: Twilio, Mailgun, SendGrid, SMS и voice;
• external tooling: OpenAI, Anthropic, GitHub, monitoring, CI/CD, design tools.

Дальше каждому платежу нужны не просто реквизиты банка, а нормальные машинно-читаемые атрибуты: vendor, contract_ref, invoice_ref, project_code, cost_center, environment, service_type, beneficiary_country, approved_by. Без этого потом невозможно быстро собрать картину, почему конкретный зарубежный расход появился и к чему он относится.

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

type ForeignExpense = {
  id: string
  vendor: 'aws' | 'gcp' | 'openai' | 'twilio' | 'other'
  amount: number
  currency: 'USD' | 'EUR' | 'GBP'
  invoiceRef: string
  contractRef?: string
  projectCode: string
  costCenter: 'platform' | 'client-work' | 'r&d' | 'ops'
  serviceType: 'hosting' | 'api' | 'communication' | 'software'
  beneficiaryCountry: string
  paymentMethod: 'corporate-card' | 'bank-transfer'
  approvedBy: string
  paidAt: string
}

Это не “юридическая норма в коде”, а инженерная дисциплина. Но именно она позволяет потом объяснить, почему платёж в OpenAI — это расход продукта X, а не абстрактная внешняя подписка, купленная непонятно кем. Для резидента ПВТ такая объяснимость стоит дорого просто потому, что льготный режим без хорошего учёта быстро превращается в лишние вопросы со стороны финблока и аудиторов.

Что ломает систему чаще всего

Обычно не закон ломает продукт, а лень на этапе проектирования.

Я чаще всего вижу четыре типовые ошибки.

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

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

Третья: нет разделения между своими продуктами и аутсорсными клиентскими расходами. Через полгода у тебя уже никто не понимает, где внутренний R&D, а где инфраструктура клиента.

Четвёртая: нет события “approved” в принципе. Платёж существует, потому что карта не была заблокирована банком. Для стартапа это звучит знакомо, но для нормального финтеха так жить нельзя.

Что поменялось по онлайн-казино и почему это касается не только казино

Самый недооценённый кусок темы — игорное регулирование. Многие читают Указ Президента №226 «О деятельности в сфере игорного бизнеса» как документ для казино и букмекерок. Это слишком узкий взгляд.

По официальному сообщению МНС от 6 февраля 2026 года и последующей публикации МНС/БЕЛТА после вступления норм в силу, с 11 марта 2026 года физлица — граждане Беларуси не могут перечислять деньги в пользу иностранных онлайн-казино: банки-эмитенты карточек должны отказывать в таких операциях. Параллельно уточнён порядок работы отрасли через постановление Совмина №764 от 24 декабря 2025 года.

Для меня здесь важен не только сам запрет. Важен инженерный вывод: если ты делаешь кошелёк, платёжный кабинет, карту, top-up flow, P2P-платформу или любую систему, через которую пользователь двигает деньги наружу, тебе уже нельзя мыслить только категориями “успешный платёж / неуспешный платёж”. У тебя должен быть слой оценки назначения операции.

И это не история про один MCC-код. Если ограничиться только MCC, продукт будет либо слепым, либо начнёт банить нормальные операции. Я бы делал фильтр из нескольких сигналов сразу: merchant descriptor, acquiring country, BIN-паттерны, whitelist/denylist контрагентов, тип канала пополнения, повторяемость операций, устройство, история аккаунта.

Как выглядит анти-казино фильтр в нормальном продукте

Я бы разбил такой фильтр на пять этапов.

1. Нормализация платёжных данных

Сначала ты приводишь к общему виду всё, что приходит из банка, PSP или процессинга: descriptor, merchant name, MCC, country, acquirer, channel, tokenized card id, wallet id.

2. Правила жёсткой блокировки

Потом идёт слой deny rules. Например, если контрагент уже есть в внутреннем чёрном списке или совпадает с известным паттерном иностранного gambling-мерчанта, операция сразу уходит в reject.

function shouldReject(tx: Tx): boolean {
  if (tx.country !== 'BY' && tx.riskTags.includes('foreign_gambling')) return true
  if (tx.mcc && BLOCKED_MCC.has(tx.mcc) && tx.direction === 'topup') return true
  if (DENYLIST_MERCHANTS.has(tx.normalizedMerchant)) return true
  return false
}

3. Слой “не уверен — не пропускай молча”

Есть операции, которые не выглядят как казино в лоб, но пахнут серой схемой: странный descriptor, слишком много мелких повторных попыток, нет нормального merchant profile, география не бьётся с продуктом. Такие вещи я не пропускал бы автоматически. Их лучше переводить в pending_review или в step-up verification.

4. Аудит-лог решения

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

5. Управление списками и версиями правил

Самая частая архитектурная ошибка — зашить риск-правила прямо в backend и катать релизы ради каждого обновления. Я предпочитаю выносить deny/allow lists и часть rule engine в отдельную конфигурируемую подсистему с версионированием. Тогда compliance-команда и разработка не мешают друг другу.

Где здесь граница между законом и инженерией

Закон не пишет тебе JSON-схему и не диктует названия полей. Закон задаёт ограничения и последствия. Инженерия переводит это в продуктовые решения.

Поэтому я бы разделял две вещи.

Первая — буквальные нормы. Их нужно читать в официальных источниках: Указ №226, постановление №764, разъяснения МНС, официальные материалы о льготах ПВТ. Актуальность лучше перепроверять перед внедрением, потому что такие темы спокойно меняются постановлением или письмом регулятора.

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

Что это значит на практике

Если ты фрилансер или маленькая студия на аутсорсе, вывод простой: не обещай финтех-клиенту “подключим платежи и дальше разберёмся”. В Беларуси это уже слабый подход. Нужен дизайн логики отказов, логов и маршрутизации расходов сразу.

Если ты CTO резидента ПВТ, смотри на зарубежные платежи не как на бухгалтерскую мелочь, а как на часть продуктовой архитектуры. Хороший ledger по расходам спасает не только налоги, но и дебаг бюджета.

Если ты владелец продукта с картами, кошельками или пополнением баланса, с марта 2026 года игнорировать сценарии, связанные с иностранными онлайн-казино, уже просто рискованно. Даже если твой продукт не про гемблинг, платёжный канал может пересечься с этой зоной.

Если ты разработчик, который делает backend для финтеха, твоя ценность теперь не в том, что ты “поднимешь FastAPI и webhook”. Ценность в том, что ты умеешь превратить требования регулятора в таблицы, очереди, события, reason codes и audit trail.

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

Если нужен такой слой комплаенса в продукте — напиши мне в Telegram или через velutich.com.