Платёжная готовность офшорного онлайн-казино в 2026 году

Как подготовить проект к проверке PSPPSP означает Payment Service Provider — платёжного провайдера, который помогает оператору принимать депозиты, обрабатывать платежи и расчёты, управлять возвратами, чарджбэками, резервами и, в некоторых моделях, потоками выплат., эквайром, EMIEMI означает Electronic Money Institution. Это учреждение электронных денег, которое может открывать счета, выпускать электронные деньги и обслуживать платежные операции в рамках своей лицензии., Visa, Mastercard и криптопровайдером

Юридическое и платёжное руководство для основателей, операторов и руководителей юридической функции

Дисклеймер. High-Risk Licensing – аналитический B2B-ресурс о лицензировании, платёжной архитектуре и регуляторных рисках. Материал носит информационный характер и не заменяет юридический анализ конкретного проекта. Требования платёжных систем, банков, PSP, EMI, криптопровайдеров и национальных регуляторов меняются. Перед запуском необходимо повторно проверить применимое право, действующую редакцию правил провайдера, лицензионный периметр и фактическую структуру движения средств.

Содержание

1. Что такое платёжная готовность онлайн-казино
2. Кто участвует в платёжной цепочке
3. Карта применимых юрисдикций
4. Семь шлюзов платёжной готовности
5. Что фактически требуют Visa и Mastercard
6. Как должна выглядеть схема движения средств
7. Криптоплатежи: дополнительный, а не упрощённый контур
8. PCI DSS, платёжная страница и техническая готовность
9. AML/KYC и ответственная игра как часть платёжной проверки
10. Финансовая модель, скользящий резерв и способность пережить сбой
11. Пакет доказательств до первой заявки
12. Что должно совпадать во всех документах
13. Критические препятствия: когда заявку подавать нельзя
14. Диагностическая шкала готовности
15. Пошаговый алгоритм подключения
16. Что контролировать после запуска
17. Типовые причины отказа
18. Мифы и реальность
19. Стратегические рекомендации
20. Часто задаваемые вопросы
21. Вывод

Короткий ответ

Платёжная готовность онлайн-казино – это способность проекта доказать, что его юридическая структура, продукт, целевые рынки, платёжная страница, AMLAML / CFT означает Anti-Money Laundering / Combating the Financing of Terrorism. По-русски: меры против отмывания денег и финансирования терроризма./KYC-контроли, финансовая модель и реальное движение денег образуют одну прозрачную и управляемую систему.

Офшорная игорная лицензия может быть обязательным входным условием, но сама по себе не даёт права на мерчант-аккаунт и не обязывает PSP принимать проект. Эквайр и его банковская цепочка проверяют не только наличие лицензии, но и законность работы в каждой стране игрока, личность фактического мерчанта, корректность MCCMCC означает Merchant Category Code. Это код категории бизнеса в карточных платежах., происхождение капитала, платёжную безопасность, схему депозитов и выплат, историю жалоб, мошенничество, чарджбеки и способность оператора пережить резервирование или задержку расчётов.

Главная практическая мысль: задача состоит не в том, чтобы найти «PSP для казино вообще», а в том, чтобы создать проверяемый риск-профиль, который соответствует лицензии, продукту, GEOGEO — страны или рынки, на которые ориентируется оператор: где он принимает игроков, покупает трафик, запускает аффилиатные кампании, принимает платежи или размещает рекламу. и политике допустимого риска конкретного платёжного партнёра.

Что изменилось в 2026 году

ПРОВЕРЕННЫЙ ФАКТОсновные правила Visa и правила продуктов и услуг Visa (Visa Core Rules and Visa Product and Service Rules) в редакции от 18 апреля 2026 года требуют, чтобы мерчант онлайн-гемблинга имел действующую лицензию или иное надлежащее разрешение и маркировал онлайн-гемблинг-операции как MCC 7995. Для операций, включающих конвертацию фиата в криптоактивы, применяется дополнительный идентификатор. Выплата выигрыша на карту производится через исходную кредитовую операцию (Original Credit Transaction, OCT), а в Европе – на тот же платёжный инструмент, который использовался для выигрышной ставки. [1]

ПРОВЕРЕННЫЙ ФАКТПравила Mastercard от 2 июня 2026 года и Правила и процедуры безопасности для мерчантов (Security Rules and Procedures – Merchant Edition) от 3 февраля 2026 года предусматривают отдельную регистрацию мерчантов дистанционного гемблинга, раскрытие URL, владельцев, платежных процедур и контролей, подтверждение законности деятельности в применимых юрисдикциях и постоянный мониторинг. [2] [3]

ПРОВЕРЕННЫЙ ФАКТPCI DSS 4.0.1 остаётся базовым стандартом защиты карточных данных. Даже оператор, который передал обработку карты внешнему процессору и использует перенаправление или iframe, не освобождается от всех обязанностей по безопасности своей электронной коммерции. Для SAQ A в 2026 году сохраняются, в частности, требования к внешнему ASV-сканированию применимых интернет-ресурсов и подтверждению того, что сайт не уязвим для атак через скрипты. [4] [5]

ПРОВЕРЕННЫЙ ФАКТМаксимальный общеевропейский переходный период MiCAMiCA — Regulation (EU) 2023/1114 on Markets in Crypto-Assets, регламент ЕС о рынках криптоактивов и провайдерах соответствующих услуг. для ранее действовавших криптопровайдеров завершился 1 июля 2026 года. Статус европейского CASPCASP означает Crypto-Asset Service Provider. MiCA использует этот термин в ЕС для провайдеров услуг с криптоактивами. теперь необходимо проверять по актуальному реестру ESMA и реестру соответствующего национального органа. [6]

АНАЛИТИЧЕСКИЙ ВЫВОДВ 2026 году платёжный партнёр оценивает не отдельный документ, а способность всей системы сохранять юридическую и операционную целостность после подключения. Слабое место в GEO, идентификации мерчанта, схеме выплат или криптоконвертации способно обнулить ценность качественного AML-пакета и даже действующей лицензии.

Что такое платёжная готовность онлайн-казино

Платёжная готовность – это не наличие банковского счёта, письма от посредника или предварительного тарифного предложения. Это доказанная способность проекта пройти пять последовательных этапов:

1. предварительный отбор провайдера;
2. корпоративную и регуляторную проверку;
3. коммерческую и финансовую проверку риска;
4. техническую интеграцию и тестирование;
5. постоянный мониторинг после запуска.

Проект считается платёжно готовым, когда сведения в анкете PSP совпадают с фактическим продуктом, договорными ролями, сайтом, рекламой, лицензионным реестром, расчётными счетами, MID, политиками и техническими настройками.

Пять уровней платёжной готовности

АНАЛИТИЧЕСКИЙ ВЫВОДДокумент без операционного доказательства имеет ограниченную ценность. Политика, которая обещает проверку возраста, но не показывает точку срабатывания, владельца контроля, источник данных и журнал решения, обычно воспринимается как шаблон, а не как работающий контроль.

Кто участвует в платёжной цепочке

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

Фактического получателя платежа (фактический получатель платежа) нельзя определять только по договору

Фактический мерчант определяется совокупностью признаков:

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

Прямой мерчант, спонсируемый мерчант и платформенная модель

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

Карта применимых юрисдикций

Одной офшорной лицензии недостаточно, потому что одна операция может одновременно затрагивать несколько правопорядков.

Как должна выглядеть GEO-матрица

Для каждой страны нужна отдельная строка, а не единый список «запрещённых государств».

Почему одного IP-блокирования недостаточно

Игрок может использовать VPN, карту другой страны, документ одной юрисдикции и фактически находиться в другой. Поэтому серьёзный GEO-контроль сопоставляет несколько сигналов:

• IP и геолокацию устройства;
• страну документа и адрес проживания;
• телефонный код и SIM-сигналы;
• BIN карты и страну платёжного метода;
• язык, валюту и рекламный источник;
• историю входов и резкие изменения локации;
• адрес некастодиального кошелька или данные CASP, если доступны;
• выявленные вручную красные флаги.
• АНАЛИТИЧЕСКИЙ ВЫВОДДля PSP важна не декларация «мы не принимаем игроков из страны X», а доказательство, что сайт, SEO, аффилиаты, платёжные методы и технические правила не противоречат этой декларации.

Семь шлюзов платёжной готовности

Шлюз 1. Идентичность и прозрачность группы

Нужно установить:

• лицензиата;
• фактический получатель платежа;
• владельца домена;
• владельца платформы и IP;
• UBO и контролирующих лиц;
• директоров и уполномоченных подписантов;
• связанные компании в платёжной цепочке;
• источник стартового капитала;
• предыдущие гемблинг- и высокорисковые проекты ключевых лиц.
• Типичный провал: анкета PSP показывает одну структуру, Правила и условия – другую, а расчётные средства поступают третьей компании.

Шлюз 2. Правовая допустимость продукта и GEO

Проверяется не только лицензия, но и:

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

Шлюз 3. Правильная классификация и регистрация

Карточная операция должна описывать реальный бизнес.

ПРОВЕРЕННЫЙ ФАКТVisa требует использовать MCC 7995 для операций онлайн-гемблинга даже тогда, когда гемблинг не является основной деятельностью мерчанта. Visa также требует правильно идентифицировать связанные переводы средств и устанавливает специальные правила для выплат выигрышей. [1]

ПРОВЕРЕННЫЙ ФАКТMastercard относит дистанционный гемблинг к специальным категориям мерчантов. Эквайр подтверждает законность деятельности в соответствующих юрисдикциях, регистрирует URL и сведения о владельцах и предоставляет описание платёжных процедур, раскрытий, возвратов и мер безопасности. [3]

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

Шлюз 4. Целостность движения средств

Схема должна отвечать на вопросы:

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

Шлюз 5. Исполнение AML, KYC, санкционных и антифрод-контролей

Минимальная архитектура должна включать:

• возрастную проверку;
• идентификацию и верификацию клиента;
• EDDEDD означает Enhanced Due Diligence. Это усиленная проверка клиента, UBO, игрока, партнера или транзакции. и условия запуска проверки происхождения средств;
• PEPPEP означает Politically Exposed Person. Это политически значимое лицо, а также в ряде случаев его родственники и близкие связанные лица. и санкционный проверка;
• сигналы риска по устройству и поведению;
• лимиты частоты и объёма операций;
• выявление повторных учётных записей;
• проверку принадлежности платёжного инструмента;
• контроль депозиты третьих лиц;
• мониторинг депозитов, игры и вывода в едином контексте;
• ведение дел и журнал аудита;
• передачу дела MLRO или иному ответственному лицу.
• Типичный провал: KYC проводится только перед выплатой, но платёжная и игровая активность до этого момента не анализируются как единый риск-профиль.

Шлюз 6. Платёжная безопасность и управление спорами

Нужно доказать:

• определённый область действия PCI DSS;
• корректный SAQ либо ROC/AOC;
• защищённую интеграцию платёжной страницы;
• контроль скриптов и изменений;
• сканирование ASV, если применимо;
• токенизацию и отсутствие ненужного хранения PAN;
• применение 3-D Secure и риск-ориентированную аутентификацию;
• понятное обозначение операции в банковской выписке;
• доступный службу поддержки;
• прозрачные условия бонусов, отмены операций, возвратов и выплат;
• сбор доказательства для рассмотрения оспариваний платежей;
• классификацию причин чарджбеки по источникам трафика и продуктам.
• Типичный провал: оператор полностью полагается на внешнюю платёжную страницу и считает, что его собственный сайт, скрипты и цепочка перенаправлений больше не входят в платёжный риск.

Шлюз 7. Финансовая устойчивость и непрерывность

Провайдер оценивает не только оборот, но и потенциальный убыток.

Нужно моделировать:

• валовые и чистые депозиты;
• долю выплат;
• средний чек;
• валюты;
• сценарии возвратов и чарджбеков;
• скользящий резерв;
• задержку расчётов;
• штрафы и отрицательный баланс;
• сезонные пики;
• концентрацию на одном PSP;
• выплаты игрокам при прекращении депозитов;
• альтернативный канал без скрытого переключения MID.
• Типичный провал: прогноз показывает оборот и доход, но не показывает обязательства перед игроками и потребность в ликвидности при резервировании 5–10% средств или задержке расчётов.

Что фактически требуют Visa и Mastercard

Важно понимать границу источника:

• правила Visa и Mastercard обязательны для участников соответствующей сети;
• эквайр переносит часть требований на мерчанта договором;
• PSP может устанавливать более строгий политика допустимого риска;
• локальное право может запрещать то, что технически допускает карточная система;
• предварительное одобрение посредника не равно одобрению эквайра или банка.
• ПРОВЕРЕННЫЙ ФАКТПрограмма Visa VAMP объединяет мониторинг мошенничества, оспариваний платежей и массового подбора реквизитов карт и применяется не только на уровне портфеля эквайра, но и к отдельным мерчантам. [7]
• ПРОВЕРЕННЫЙ ФАКТПравила безопасности Mastercard предусматривают проверку новых мерчантов и постоянный мониторинг, включая программы контроля чрезмерных чарджбеков (ECP), оценки и снижения бизнес-риска (BRAM), мониторинга мерчантов (MMP) и MATCH Pro. [3]

АНАЛИТИЧЕСКИЙ ВЫВОДPSP заинтересован не только в том, чтобы оператор оставался ниже формального порога программы мониторинга. Провайдеру важно заранее понимать происхождение мошенничества и оспариваний платежей и видеть, что оператор умеет остановить проблемный канал до того, как риск повлияет на весь портфель эквайринга.

Как должна выглядеть схема движения средств

Минимальная схема должна отображать не только стрелку «игрок → PSP → казино», а полный жизненный цикл денег.

Карточный депозит

1. Игрок проходит применимые регистрацию и возрастные ограничения.
2. Платёжная страница показывает юридическое название мерчанта, сумму, валюту и условия.
3. PSP или платёжный шлюз передаёт данные эквайру.
4. Операция направляется эмитенту с правильным MCC и данными электронной торговли.
5. После авторизации сумма отражается в игровом учёте.
6. Расчётные средства поступают на раскрытый счёт фактического получателя платежа.
7. Комиссии и скользящий резерв учитываются отдельно.

Возврат

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

Выплата выигрыша

ПРОВЕРЕННЫЙ ФАКТПо правилам Visa выигрыш на карту выплачивается посредством OCT. Для Европы OCT должен направляться на тот же платёжный реквизит, который использовался для выигрышной ставки. [1]

Оператору нужна матрица исключений для ситуаций, когда:

• карта закрыта или истекла;
• эмитент не принимает OCT;
• депозит был сделан несколькими методами;
• игрок использовал APM;
• сумма выплаты превышает депозит;
• требуется дополнительная SOF/EDD-проверка;
• платёжный метод недоступен в стране игрока.

Запрещённая конструкция

Следующая модель создаёт критический риск:

игрок платит компании A → операция маркируется нейтральным MCC → расчёты получает компания B → баланс ведёт лицензиат C → выплату делает нераскрытый криптокошелёк D.

Такая схема может одновременно вызвать вопросы о скрытой обработке чужих транзакций (transaction laundering), законности приёма средств, AML-обязанностях, налоговом учёте, защите средств игрока и достоверности данных, предоставленных эквайру.

Криптоплатежи: дополнительный, а не упрощённый контур

Криптовалюта не устраняет платёжную проверку. Она добавляет новый набор участников, рисков и доказательств.

Вопросы, на которые должен ответить проект

1. Кто принимает криптоактив от игрока?
2. Кто контролирует депозитный адрес?
3. Является ли кошелёк кастодиальным или некастодиальным?
4. Кто проводит проверку кошелька и санкционную проверку?
5. Кто выполняет мониторинг операций и устанавливает оценку риска?
6. Кто является регулируемым CASP/VASP и в какой юрисдикции?
7. Где происходит конвертация фиатных денег в криптоактивы и обратно?
8. На каком этапе фиксируется обменный курс и кто несёт риск волатильности?
9. Кто собирает и передаёт сведения по Travel Rule?
10. Как подтверждается владение адрес некастодиального кошелька?
11. Можно ли вывести средства на адрес, который не использовался для депозита?
12. Как сопоставляются клиент, адрес, транзакция, игровой учёт и выплата?

Комплексная проверка CASP/VASP

Проверка провайдера должна включать:

• юридическое лицо и торговое название;
• лицензию или регистрацию;
• перечень разрешённых услуг;
• страны, где он может работать;
• актуальный реестр регулятора;
• банковских партнёров и поставщиков ликвидности;
• модель хранения активов;
• решение для выполнения Travel Rule;
• поставщика блокчейн-аналитики;
• санкционную политику и правила в отношении запрещённых активов;
• обработку миксеры, сервисы смешивания, конфиденциальные монеты и высокорисковые сервисы;
• процедуры реагирования на инциденты и возврата активов;
• субподрядчиков;
• условия прекращения договора и право на выгрузку данных.
• ПРОВЕРЕННЫЙ ФАКТРуководящие принципы EBA по Travel Rule применяются с 30 декабря 2024 года и определяют сведения, сопровождающие переводы криптоактивов, а также действия CASP при неполных данных и переводах на адреса некастодиальных кошельков или с них. [8]
• ПРОВЕРЕННЫЙ ФАКТПри переводе свыше 1 000 евро на адрес некастодиального кошелька или с него Регламент (ЕС) 2023/1113 предусматривает проверку того, что адрес принадлежит клиенту или контролируется им. [9]

Методы подтверждения некастодиального кошелька

В зависимости от риска и решения CASP могут использоваться:

• криптографическое подписание сообщения;
• микроперевод или подтверждение операции;
• подключение кошелька и проверка по схеме «запрос-ответ»;
• снимок экрана или видеоподтверждение как вспомогательное доказательство;
• блокчейн-аналитику и историю владения;
• подтверждение через ранее верифицированный адрес;
• дополнительные сведения о третьем лице, если адрес принадлежит не клиенту.
• Ни один метод не следует описывать как универсально достаточный. Итоговый стандарт зависит от применимого права, политики CASP, суммы и риск-профиля.

Критические препятствия для криптоплатежей

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

PCI DSS, платёжная страница и техническая готовность

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

Даже если карточные поля предоставляет внешний процессор, сайт оператора может повлиять на безопасность платежа через:

• вредоносный JavaScript;
• подмену перенаправления;
• изменение iframe;
• компрометацию сторонних скриптов;
• поддельную платёжную страницу;
• утечку токенов и данных сессии;
• небезопасную админ-панель;
• неконтролируемое развёртывание.

ПРОВЕРЕННЫЙ ФАКТPCI SSC указывает, что SAQ A применяется, когда элементы платёжной страницы поступают непосредственно от стороннего провайдера с подтверждённым соответствием PCI DSS. Для встроенного iframe сайт мерчанта должен также подтвердить защищённость от атак через скрипты. [4]

ПРОВЕРЕННЫЙ ФАКТВ июне 2026 года PCI SSC подтвердил, что требования к внешнему сканированию ASV в SAQ A распространяются и на страницы электронной торговли с перенаправлением или встроенным iframe в предусмотренном стандартом объёме. [5]

Минимальный технический пакет

• схема потоков данных
• определение среду карточных данных (CDE) и область действия PCI DSS
• SAQ, AOC или ROC, применимые к модели
• AOC процессора и хостинга
• реестр скриптов на страницах, связанных с платежами
• механизмы авторизации, проверки целостности и выявления подмены
• отчёты сканирования ASV
• управление уязвимостями
• управление доступом и многофакторную аутентификацию (MFA)
• безопасный жизненный цикл разработки (SDLC) и управление изменениями
• план реагирования на инциденты
• журналы платёжных событий
• настройки 3-D Secure и логику исключений
• правила выявления мошенничества и ручную проверку
• сроки хранения и удаления данных.

3-D Secure не заменяет антифрод

3-D Secure помогает аутентифицировать держателя карты и может влиять на распределение ответственности, но не отвечает на вопросы:

• разрешён ли игрок по GEO;
• принадлежит ли ему платёжный инструмент;
• используется ли чужая или похищенная личность;
• связан ли аккаунт со злоупотреблением бонусами;
• является ли депозит частью схемы отмывания средств;
• соответствует ли последующая выплата профилю игрока.
• Поэтому 3-D Secure, анализ устройства, поведенческий анализ, лимиты частоты операций, KYC и мониторинг операций должны работать как единая система.

AML/KYC и ответственная игра как часть платёжной проверки

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

Контрольная карта

Что нужно показать PSP

Не только политику, но и:

• матрицу правил;
• ответственных за меры контроля;
• пороговые значения и их обоснование;
• примеры сигналов;
• сроки обработки;
• порядок эскалации;
• журналы решений;
• контроль качества;
• периодическое тестирование;
• отчётность руководству;
• изменения после выявленного инцидента.
• АНАЛИТИЧЕСКИЙ ВЫВОДДля стартапа отсутствие исторических данных не является автоматическим препятствием. Но прогнозные пороговые значения должны быть обоснованы, меры контроля – настроены до запуска, а первые недели работы – покрыты усиленным мониторингом.

Финансовая модель, скользящий резерв и способность пережить сбой

Какие цифры запросит андеррайтер

• ожидаемый ежемесячный объём процессинга
• количество и средний размер депозитов
• доля новых и повторных игроков
• распределение по GEO и валютам
• долю выплат
• доля возвратов
• прогноз по чарджбекам
• прогноз по мошенничеству
• ожидаемые GGRGGR означает Gross Gaming Revenue. Это валовой игровой доход: разница между суммой ставок игроков и выплаченными выигрышами до вычета некоторых расходов. и NGRNGR означает Net Gaming Revenue. Обычно это GGR за вычетом бонусов, возвратов, чарджбэков, платёжных комиссий, налогов, отчислений в джекпоты и иных согласованных удержаний. Точная формула зависит от договора.
• каналы привлечения
• максимальная ежедневная выплата
• доступный оборотный капитал
• существующие долги и обязательства
• история процессинга, если она есть.

Скользящий резерв нужно считать как риск ликвидности

Резерв – это не только комиссия. Он временно изымает часть расчёты из оборота. Для оператора важно смоделировать:

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

Стресс-тест

Минимальный сценарий должен отвечать на вопрос:

Может ли оператор в течение 30 дней выплачивать игрокам средства, если основной PSP остановит новые депозиты, удержит расчёты и увеличит резерв?

В модели должны быть как минимум три сценария:

1. базовый;
2. повышенный уровень оспариваний платежей и резерва;
3. прекращение процессинга с сохранением обязательств по выплатам.

НЕПОДТВЕРЖДЕННАЯ ИНФОРМАЦИЯПо мере усиления мониторинга портфелей эквайринга провайдеры будут чаще требовать не только прогноз оборота, но и доказательства того, что казначейство оператора отделяет средства для выплат от бюджета роста и маркетинга.

Пакет доказательств до первой заявки

11.1. Краткий профиль мерчанта для предварительной оценки

Документ на 2–4 страницы должен содержать:

• юридическое лицо и юрисдикцию;
• тип лицензии и регулятора;
• продукты;
• целевые и исключённые GEO;
• ожидаемые объёмы;
• валюты и способы оплаты;
• модель депозитов и выплат;
• наличие криптоплатежей;
• краткое описание KYC/AML;
• историю процессинга;
• запрашиваемую услугу;
• готовность раскрыть полный пакет после подтверждения политика допустимого риска.
• Анонимизированный профиль полезен для первичного отбора, но не заменяет KYC. Некоторые провайдеры не дают содержательной оценки без названия компании, UBO и домена.

11.2. Полный пакет для проверки риска

11.3. Индекс доказательств

Каждый факт должен иметь:

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

Что должно совпадать во всех документах

Критические препятствия: когда заявку подавать нельзя

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

1. Лицензия не проверяется или не покрывает продукт.
2. Домен отсутствует в требуемом лицензионном периметре.
3. фактический получатель платежа не совпадает с раскрытой игроку стороной и роль не объяснена.
4. Используется чужой, арендованный или нераскрытый MID.
5. Гемблинг маскируется нейтральным MCC или ложным описанием.
6. Проект фактически принимает запрещённые GEO.
7. Нет законной и технически реализуемой модели выплата.
8. UBO, SOF/SOW или санкционные риски не закрыты.
9. Расчёты или конвертация криптоактивов проходят через нераскрытое лицо.
10. PSP или эквайр прямо запрещает соответствующую модель.
11. Отсутствует минимальная PCI и безопасность платёжной страницы архитектура.
12. У оператора нет ликвидности для выплат при резерве или остановке депозитов.
13. Диагностическая шкала готовности

После прохождения критических препятствий каждый блок оценивается от 0 до 3:

• 0 – доказательство отсутствует;
• 1 – документ есть, но остаются существенные противоречия;
• 2 – документ и базовый операционное доказательство согласованы;
• 3 – контроль протестирован, имеет владельца, метрики и механизм обновления.

Этап 1. Зафиксировать модель

1. Определить лицензиата и фактический получатель платежа.
2. Нарисовать структуру группы и схему движения средств.
3. Назвать все банки, EMI, PSP, CASP и платёжных посредников.
4. Разделить депозиты, возвраты, выплаты и конвертацию криптоактивов.

Этап 2. Проверить право и GEO

1. Проверить лицензию, домены и продукты по первичным источникам.
2. Сформировать правовую матрицу по каждой стране.
3. Настроить технические и маркетинговые блокировки.
4. Проверить правила аффилиатов и локальные посадочные страницы.

Этап 3. Подготовить меры контроля

1. Настроить KYC/AML, санкционные, антифрод-меры и контроль выплат.
2. Определить область действия PCI DSS и закрыть безопасность платёжной страницы.
3. Создать процессы реагирования на инциденты, жалобы, возвраты и чарджбеки.
4. Провести внутреннюю сквозную проверку на реальных пользовательских сценариях.

Этап 4. Подготовить доказательства

1. Создать короткий профиль мерчанта.
2. Собрать полный пакет для проверки риска.
3. Создать реестр доказательств.
4. Провести проверку согласованности сайта, договоров, схем и анкеты.

Этап 5. Выбрать провайдера

1. Проверить, принимает ли провайдер именно такую лицензию, продукт, GEO и модель мерчанта.
2. Уточнить, кто является фактическим эквайром и расчётным банком.
3. Провести предварительную оценку без сокрытия материальных фактов.
4. Не направлять полный UBO-пакет массово непроверенным посредникам.

Этап 6. Пройти проверку риска

1. Вести единый журнал вопросов и ответов.
2. Не менять ответы между PSP, EMI и эквайром.
3. Документировать все допущения и будущие изменения.
4. Согласовать MCC, обозначение операции в выписке, валюты, страны, резерв, лимиты и правила выплат.

Этап 7. Запуск и мониторинг

1. Провести тестовые операции от авторизации до выплата/возврат.
2. Проверить обозначение операции в банковской выписке и сценарии работы поддержки.
3. Установить ежедневные и еженедельные панели рисковых показателей.
4. Согласовать процедуру уведомления об изменениях.
5. Подготовить резервный план без скрытого перенаправления операций.
6. Проводить периодическую повторную проверку пакета доказательств.
7. Что контролировать после запуска

Одобрение PSP не является бессрочным разрешением. Следующие изменения обычно требуют внутренней проверки, а иногда предварительного уведомления или согласия провайдера:

• новый домен или зеркало;
• новое GEO;
• букмекерский продукт, казино с живыми дилерами, скины, лотереи или криптовалютная функция;
• смена фактический получатель платежа;
• новый UBO или директор;
• изменение обозначения операции в банковской выписке;
• новый PSP, EMI, CASP или канал выплат;
• новый аффилиатная сеть;
• резкий рост объёма или средний чек;
• рост возвратов, мошенничества или оспариваний платежей;
• изменение платёжной страницы;
• новый способ хранения или конвертации активов;
• регуляторная жалоба, расследование или значимый инцидент;
• негативные публикации;
• изменение лицензии или доменного периметра.

Минимальная панель показателей

• доля успешных авторизаций
• доля операций с запросом 3-D Secure и без дополнительного запроса
• уровень мошенничества
• количество и сумма оспариваний платежей
• доля возвратов
• доля отклонённых выплат
• средний депозит и средняя выплата
• несоответствие GEO и страны BIN
• сигналы платежей третьих лиц
• срок завершения KYC
• совпадения по санкционным спискам и PEP
• показатели аффилиатных источников
• жалобы по первопричинам
• задержку расчётов
• использование резерва
• доля высокорисковых криптоопераций.

НЕПОДТВЕРЖДЕННАЯ ИНФОРМАЦИЯПереносимый пакет доказательств и зрелое управление изменениями будут становиться более ценным активом, чем единичный «контакт PSP», поскольку отношения с эквайрами в высокорисковых отраслях остаются подвержены пересмотру, миграции и прекращению.

Юридические

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

Корпоративные

• непрозрачный UBO
• номинальная структура без объяснения
• несоответствие SOF/SOW
• негативная история директоров
• связанные закрытые мерчант-счета.

Продуктовые

• нераскрытый букмекерский, криптовалютный продукт или функции со скинами
• вводящие в заблуждение бонусные условия
• отсутствие меры ответственной игры

роли в модели White-labelWhite-label — модель, при которой оператор запускает бренд на инфраструктуре другого лицензированного или технического провайдера. Такой провайдер часто контролирует платформу, часть комплаенса, платежи, игры, административную систему и иногда лицензионную структуру. не определены.

Платёжные

• неправильный MCC
• нераскрытая агрегация
• выплата через третье лицо
• непонятное обозначение операции в выписке
• чрезмерные повторные попытки или тестирование карт
• отсутствие принцип замкнутого платёжного контура.

Технические

• неопределённый область действия PCI DSS
• небезопасная платёжная страница
• отсутствие ASV или требуемой валидации
• неконтролируемые скрипты
• слабое управление доступом.

Финансовые

• недостаточная ликвидность
• нереалистичный прогноз
• отсутствие резерва на выплаты и чарджбеки
• критическая зависимость от одного канала.

Репутационные

• массовые жалобы на невыплаты
• непрозрачные условия бонусов
• вводящая в заблуждение реклама
• значимые неурегулированные споры
• негативные данные в системах проверки мерчантов.

Мифы и реальность

Стратегические рекомендации

1. Проектируйте платёжную архитектуру одновременно с лицензированием, а не после запуска сайта.
2. Начинайте с фактический получатель платежа и движения средств, а не со списка «доступных PSP».
3. Разделяйте обязательное правило сети, локальное право и коммерческую политику провайдера.
4. Для каждого GEO связывайте юридический вывод с техническим и маркетинговым контролем.
5. Не передавайте платёжные функции компании, которая не имеет прозрачной роли перед игроком и PSP.
6. Встраивайте архитектуру выплат до начала приёма депозитов.
7. Рассматривайте криптоплатежи как отдельный регулируемый контур.
8. Собирайте операционное доказательство с первого дня, а не только политики.
9. Считайте скользящий резерв и задержку расчётов как стресс ликвидности.
10. Создайте переносимый пакет доказательств и процесс управления изменениями.

Что делать прямо сейчас

• завершить карту корпоративной структуры и ролей мерчанта
• проверить лицензию, домены и продукт
• собрать GEO-матрицу
• построить схему депозитов, возвратов, выплат и криптоконвертации
• определить область действия PCI DSS

проверить статус CASP/VASP;

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

От чего отказаться

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

Частые вопросы

Вывод

Платёжная готовность офшорного онлайн-казино – это архитектура, а не папка с документами. Рабочая модель соединяет лицензию, фактического получателя платежа, GEO, платёжную классификацию, депозит, игровой учёт, возвраты, выплаты, AML/KYC, PCI, криптоплатежи и ликвидность в одну проверяемую цепочку.

Проект получает устойчивый доступ к платежам не тогда, когда посредник обещает «открыть PSP», а тогда, когда любой существенный вопрос андеррайтера имеет согласованный ответ, первичный источник и операционное доказательство.

Источники

Информация проверена по состоянию на 26 июля 2026 года. Приоритет отдаётся официальным документам и первичным источникам. Коммерческие условия, процедуры и применимость выводов необходимо повторно проверить перед использованием материала для конкретного проекта.

1. Visa Core Rules and Visa Product and Service Rules, редакция от 18 апреля 2026 года, раздел 5.8.18 и применимые положения об обработке операций. Проверено 26 июля 2026 года — Первичный источник по платёжным требованиям, merchant risk, чарджбэкам и операционным контролям.
2. Mastercard Rules, редакция от 2 июня 2026 года. Проверено 26 июля 2026 года — Первичный источник по платёжным требованиям, merchant risk, чарджбэкам и операционным контролям.
3. Mastercard Security Rules and Procedures – Merchant Edition, редакция от 3 февраля 2026 года, главы 7–11 и раздел 9.4.2. Проверено 26 июля 2026 года — Первичный источник по платёжным требованиям, merchant risk, чарджбэкам и операционным контролям.
4. PCI Security Standards Council, FAQ 1588: применимость SAQ A и защита от атак через скрипты. Проверено 26 июля 2026 года — Первичный источник по платёжным требованиям, merchant risk, чарджбэкам и операционным контролям.
5. PCI Security Standards Council, FAQ 1604: сканирование ASV для страниц электронной торговли в рамках SAQ A, июнь 2026 года. Проверено 26 июля 2026 года — Первичный источник по платёжным требованиям, merchant risk, чарджбэкам и операционным контролям.
6. ESMA, Markets in Crypto-Assets Regulation (MiCA): временный реестр MiCA и переходные меры; реестр обновлён 16 июля 2026 года. Проверено 26 июля 2026 года — Публичный реестр для проверки лицензиата, статуса лицензии, компании и связанных доменов.
7. Visa Acquirer Monitoring Program: официальные материалы программы и обновления 2025–2026 годов. Проверено 26 июля 2026 года — Первичный источник по платёжным требованиям, merchant risk, чарджбэкам и операционным контролям.
8. European Banking Authority, Travel Rule Guidelines по Регламенту (ЕС) 2023/1113, применяются с 30 декабря 2024 года. Проверено 26 июля 2026 года — Официальные требования к заявителю, документам и процедуре подачи и рассмотрения заявки.
9. Регламент (ЕС) 2023/1113 о сведениях, сопровождающих переводы средств и отдельных криптоактивов, включая положения о некастодиальных адресах. Проверено 26 июля 2026 года — Базовый нормативный акт, определяющий полномочия регулятора, лицензионный режим и ключевые обязанности.
10. PCI DSS v4.0.1: официальная страница стандарта PCI SSC и сопроводительные материалы. Проверено 26 июля 2026 года — Первичный источник по платёжным требованиям, merchant risk, чарджбэкам и операционным контролям.
11. PCI SSC, Payment Page Security and Preventing E-Skimming: руководство по требованиям 6.4.3 и 11.6.1. Проверено 26 июля 2026 года — Официальные требования к заявителю, документам и процедуре подачи и рассмотрения заявки.
12. FATF, Virtual Assets: стандарты и риск-ориентированное руководство. Проверено 26 июля 2026 года — Международный стандарт по AML/CFT, рискам виртуальных активов и применению Travel Rule.