# SERVICE\_POLICIES.md

## SERVICE\_POLICIES.md — политики CardApp

Документ фиксирует правила сервиса, согласованные в event storming-сессии. Формулировки написаны как доменные политики: что система должна делать и почему. Техническая реализация, конкретные сервисы и детали инфраструктуры могут отличаться.

***

### Acquisition, attribution и воронка

#### LIFETIME\_FIRST\_TOUCH\_ATTRIBUTION

Первая attribution-ссылка фиксируется бессрочно и не перезаписывается последующими ссылками. Пользователь регистрируется по одной ссылке: referral, affiliate или internal marketing. Если attribution уже есть, новая ссылка не меняет источник.

#### FUNNEL\_MILESTONES

Основные milestones воронки:

* регистрация завершена;
* первая карта открыта;
* первый депозит завершён.

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

#### FUNNEL\_NURTURE\_SCHEDULE\_V1

Если пользователь застрял на этапе воронки, система отправляет nurture-сообщения через:

* 15 минут;
* 24 часа;
* 72 часа;
* 7 дней.

После перехода на следующий milestone соответствующая nurture-цепочка останавливается.

#### PRE\_REGISTRATION\_NURTURE\_CHANNEL\_SELECTION

До завершения регистрации канал дожима выбирается по платформе входа:

* Telegram Mini App → Telegram bot;
* Web/landing → email;
* App Store / Google Play → email + push.

MAKS Mini App отложен на будущую версию.

#### REACTIVATION\_AFTER\_10\_DAYS\_INACTIVITY

Пользователь считается неактивным, если 10 дней не было никаких пользовательских активностей: входов, платежей, депозитов, обращений в поддержку, сообщений AI, действий с картами или рефералкой.

#### REACTIVATION\_RESPECTS\_MARKETING\_PREFERENCES

Если пользователь отключил промо/новости, reactivation-сообщения после 10 дней бездействия не отправляются.

***

### Регистрация, вход и устройства

#### REGISTRATION\_REQUIRES\_PHONE\_AND\_EMAIL\_CONFIRMATION

Пользователь считается зарегистрированным только после заполнения ФИО, телефона, email и успешного подтверждения обоих каналов.

#### OTP\_CONFIRMATION\_LIMITS

OTP для телефона и email действует 2 минуты. Максимум 5 попыток ввода. После истечения OTP пользователь может сразу запросить новый код.

#### UNIQUE\_EMAIL\_PHONE\_ACCOUNT

Email и phone уникальны для аккаунта. Если пользователь пытается зарегистрироваться с уже существующим email/phone, система сообщает, что аккаунт уже зарегистрирован, и предлагает вход.

#### PHONE\_EMAIL\_REQUIRED\_FOR\_CROSS\_PLATFORM\_LOGIN

Phone и email обязательны даже при регистрации через Telegram Mini App, чтобы пользователь мог входить через разные платформы: Web, Telegram, future mobile apps.

#### V1\_PLATFORMS\_TELEGRAM\_AND\_WEB

В первой версии фокус на Telegram Mini App и Web. MAKS Mini App оставляем на будущую версию.

#### TELEGRAM\_LOGIN\_BY\_LINKED\_IDENTITY

Если Telegram identity уже привязан к аккаунту, пользователь получает сессию. Если нет — запускается регистрация.

#### TELEGRAM\_IDENTITY\_LINKED\_ON\_REGISTRATION

При успешной регистрации через Telegram Mini App Telegram identity автоматически привязывается к созданному аккаунту.

#### WEB\_LOGIN\_BY\_EMAIL\_OR\_PHONE\_WITH\_OTP

В Web-версии пользователь входит по email или телефону через OTP/2FA.

#### NEW\_DEVICE\_REQUIRES\_2FA

При входе с нового устройства пользователь должен пройти OTP/2FA. До подтверждения устройство не считается доверенным.

#### SESSION\_REJECTED\_IF\_NEW\_DEVICE\_2FA\_FAILED

При входе с нового устройства сессия открывается только после успешного OTP/2FA. Если проверка не пройдена, сессия не создаётся.

#### USER\_CAN\_MANAGE\_TRUSTED\_DEVICES

Пользователь может просматривать доверенные устройства и отзывать их. При отзыве устройства связанные сессии прекращаются.

#### REVOKING\_CURRENT\_DEVICE\_LOGS\_OUT\_USER

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

#### TWO\_FACTOR\_METHODS\_V1

В первой версии поддерживаются:

* email OTP;
* SMS/phone OTP;
* Telegram bot code;
* app push.

#### TWO\_FACTOR\_PRIMARY\_AND\_BACKUP\_METHOD

Пользователь должен иметь основной и запасной метод 2FA для восстановления доступа и подтверждения рискованных действий.

#### TWO\_FACTOR\_METHOD\_CHANGE\_REQUIRES\_CURRENT\_2FA

Изменение основного или запасного метода 2FA требует успешного подтверждения текущим 2FA.

#### LOST\_2FA\_RECOVERY\_SUPPORT\_AND\_KYC

Если пользователь потерял доступ ко всем 2FA-методам, восстановление доступа возможно только через поддержку и успешную KYC-проверку.

***

### KYC и compliance

#### RISK\_BASED\_KYC

KYC не обязателен для всех пользователей сразу. KYC запрашивается только по риск-триггерам.

#### KYC\_DOCUMENTS\_AND\_FACE\_CHECK

Для KYC принимаются паспорт, загранпаспорт, водительское удостоверение и ВНЖ с фото. Лицевая проверка обязательна.

#### KYC\_EXTERNAL\_PROVIDER\_NO\_DOCUMENT\_STORAGE

KYC-документы обрабатывает внешний провайдер. CardApp не хранит и не просматривает документы, а получает только результат проверки и необходимые метаданные.

#### KYC\_RETRY\_LIMIT

Пользователь может повторить KYC до 5 раз за 24 часа.

#### KYC\_RETRY\_AFTER\_24H

Если пользователь исчерпал 5 KYC-попыток за 24 часа, следующая попытка доступна через 24 часа.

#### SANCTIONS\_HIT\_DEPOSIT\_RESTRICTION\_ONLY

При sanctions/PEP/watchlist hit пользователю ограничиваются депозиты, но платежи остаются доступными.

#### SANCTIONS\_REVIEW\_BY\_KYC\_PROVIDER

Sanctions/PEP/watchlist проверку проводит внешний KYC-провайдер. CardApp применяет депозитное ограничение на время проверки и снимает его после положительного финального результата провайдера.

#### FAILED\_KYC\_SUPPORT\_ASSISTED\_RETRY

При отрицательном KYC/compliance результате депозитное ограничение сохраняется. Пользователь может повторить KYC до 5 раз в день, а support помогает пройти проверку.

***

### Тарифы, FX и quote

#### TARIFFS\_ARE\_CONFIGURABLE

Тарифы, цены выпуска и FX markup являются конфигурацией и могут меняться через контролируемый процесс с audit/approval.

#### CARD\_PRICE\_BY\_TARIFF\_AND\_TYPE

Клиентская цена открытия карты рассчитывается по тарифу и типу карты: virtual или physical. Провайдерская логика остаётся внутренней и не отображается пользователю.

#### TARIFF\_LIMITS\_CONFIGURABLE\_LATER

Модель тарифов должна поддерживать депозитные и платёжные лимиты, но конкретные значения будут определены позже.

#### CARD\_ISSUANCE\_PRICE\_APPLIES\_TO\_NEW\_CARDS\_ONLY

Изменение стоимости выпуска тарифа применяется только к новым открытиям карт.

#### FX\_RATE\_APPLIES\_TO\_ALL\_CARDS

Обновлённые обменные курсы и FX markup применяются ко всем картам соответствующего тарифа/типа.

#### RUB\_PLATFORM\_RATE\_FROM\_RAPIRA\_PLUS\_MARKUP

RUB-курс платформы рассчитывается на основе курса Rapira с ручной наценкой, установленной администратором.

#### FX\_MARKUP\_BY\_TARIFF\_AND\_CARD\_TYPE

Наценка к курсу задаётся отдельно по тарифу и типу карты: virtual/physical.

#### BALANCE\_DISPLAY\_USD\_AND\_SELECTED\_CURRENCY

Основной баланс карты отображается в USD. Дополнительно показывается эквивалент в выбранной пользователем валюте по курсу, применимому к его тарифу.

#### DISPLAY\_CURRENCY\_AND\_DAILY\_FX

Пользователь выбирает валюту отображения в настройках. RUB считается по курсу платформы. EUR/GBP/другие валюты считаются по внешним курсам, обновляемым раз в день.

#### PAYMENT\_QUOTE\_TTL\_2H\_ALL\_METHODS

Quote и окно оплаты для открытия карты и пополнений через СБП/crypto действуют 2 часа. На это время фиксируются расчёт, цена, курс и резерв лимита.

***

### Открытие и выпуск карт

#### CARD\_OPENING\_MIN\_PAYMENT

Для открытия карты минимальная сумма оплаты равна стоимости карты плюс $10 первого депозита. Сумма сверх стоимости выпуска зачисляется на баланс карты. Для уже открытой карты минимальный депозит — $10.

#### CARD\_OPENED\_AFTER\_PAYMENT\_AND\_CREDENTIALS

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

#### CARD\_CREDENTIALS\_AVAILABLE\_AFTER\_ISSUANCE

После успешного выпуска реквизиты карты доступны пользователю в приложении. Каждый просмотр чувствительных реквизитов фиксируется в audit.

#### PHYSICAL\_CARD\_CREDENTIALS\_BY\_PROVIDER\_MODE

Для физической карты момент выдачи реквизитов зависит от провайдера и тарифа: сразу после выпуска, после доставки или после активации.

#### CARD\_ISSUANCE\_PROVIDER\_CASCADE

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

#### CARD\_ISSUANCE\_MAX\_WAIT\_AND\_SUPPORT\_REFUND

После оплаты карта должна быть выпущена в пределах 24-48 часов. Если выпуск не завершён в срок, создаётся кейс в поддержку, админы получают алерт, возврат средств выполняется через поддержку.

#### CARD\_ISSUANCE\_PENDING\_MESSAGE

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

#### CARD\_ISSUANCE\_DELAY\_NOTIFICATION\_V1

Если карта не выпущена в течение 24 часов после оплаты, система уведомляет пользователя о задержке и поднимает алерт администраторам.

#### CARD\_ISSUANCE\_48H\_SUPPORT\_CHOICE

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

***

### Карты: статусы, настройки, закрытие

#### CARD\_FROZEN\_VS\_BLOCKED

`Frozen` — self-service временная заморозка пользователем. `Blocked` — принудительная блокировка системой или админом; пользователь сам не может разблокировать такую карту.

#### CARD\_FREEZE\_SAFE\_UNFREEZE\_REQUIRES\_2FA

Пользователь может заморозить карту без OTP/2FA. Разморозка карты требует успешного OTP/2FA.

#### BLOCKED\_CARD\_UNBLOCK\_VIA\_SUPPORT\_ADMIN

Blocked-карту нельзя разблокировать self-service. Разблокировка возможна только через поддержку/admin flow.

#### CARD\_PAYMENT\_LIMITS

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

#### SAFE\_CARD\_RESTRICTIONS\_WITHOUT\_2FA

Действия, которые уменьшают риск, например выключение онлайн-платежей, выполняются без OTP/2FA. Действия, которые повышают риск или лимиты, требуют OTP/2FA.

#### CARD\_LIMIT\_DIRECTIONAL\_2FA

Уменьшение пользовательских лимитов карты выполняется без OTP/2FA. Увеличение пользовательских лимитов требует OTP/2FA и не может превышать тарифный лимит.

#### CARD\_CLOSURE\_VIA\_SUPPORT\_ONLY

Пользователь не может самостоятельно закрыть карту в self-service. Закрытие карты выполняется через поддержку.

#### CARD\_CLOSURE\_WAIT\_FOR\_PENDING\_ACTIVITY

Окончательное закрытие карты возможно только после завершения всех pending authorizations, открытых споров, незавершённых депозитов и ожидаемых возвратов.

#### CARD\_CLOSURE\_BALANCE\_HANDLING

При закрытии карты остаток баланса переводится на другую карту пользователя. Если подходящей карты нет или нужен ручной разбор, создаётся support/finance case.

#### EXPIRED\_CARD\_NEW\_PURCHASE\_OFFER

При истечении срока карты пользователю предлагается купить новую карту. Автоматический перевыпуск не выполняется.

***

### Физическая доставка и provider incident

#### PHYSICAL\_CARD\_DELIVERY\_FAILURE\_SUPPORT\_FLOW

Если доставка физической карты не удалась, система отправляет обязательное уведомление, автоматически создаёт тикет поддержки, а повторная доставка оформляется через поддержку/admin после уточнения адреса.

#### CARD\_PROVIDER\_INCIDENT\_RESPONSE

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

#### PROVIDER\_INCIDENT\_AUTO\_CARD\_REISSUE

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

#### OLD\_CARD\_BLOCKED\_AFTER\_PROVIDER\_INCIDENT\_REISSUE

При автоматической замене из-за provider incident старая карта помечается как blocked, новая карта выпускается за счёт сервиса.

#### AUTO\_BALANCE\_TRANSFER\_ON\_PROVIDER\_REISSUE

При автоматической замене карты из-за provider incident баланс переносится со старой blocked-карты на новую через ledger transaction.

***

### СБП-депозиты

#### DEPOSIT\_LIMIT\_PRECHECK

Перед созданием СБП/crypto-депозита система проверяет доступный депозитный лимит выбранной карты. Если сумма превышает доступный месячный/годовой лимит карты, депозит не создаётся. Пользователю предлагается выбрать другую карту с достаточным лимитом или открыть новую карту подходящего типа.

#### DEPOSIT\_LIMIT\_BY\_CREDITED\_AMOUNT\_NOT\_BALANCE

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

#### DEPOSIT\_LIMIT\_RESERVATION

При создании депозитной заявки система проверяет доступный лимит карты и резервирует сумму на время quote/payment window. Резерв снимается, если депозит отменён, истёк или не был оплачен. Резерв превращается в consumed-limit после успешного зачисления.

#### SBP\_LATE\_PAYMENT\_REFUND

Если СБП-платёж поступил после истечения 2-часового окна оплаты или завис вне нормального процесса, он не зачисляется и возвращается.

#### SBP\_COLLECT\_MAXIMUM\_PAYER\_DATA

При получении СБП-платежа система сохраняет все доступные данные о плательщике, строит payer fingerprint и фиксирует уровень полноты данных. Бизнес-решения принимаются не по одному ФИО, а по лучшему доступному набору признаков.

#### SBP\_PAYER\_PERSON\_VS\_INSTRUMENT

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

#### SBP\_SAME\_NAME\_SAME\_PERSON\_WITH\_SIGNAL\_ACCUMULATION

Если нормализованное ФИО плательщика совпадает с уже известным плательщиком, система считает это тем же человеком. Новые банки/счета/телефоны записываются как новые платёжные инструменты. Риск-сигналы накапливаются отдельно.

#### SBP\_PAYER\_NAME\_NORMALIZATION

ФИО плательщика и KYC-ФИО сравниваются после нормализации: регистр, пробелы, ё/е, порядок слов и допустимые варианты с/без отчества.

#### SBP\_REFERENCE\_PAYER\_BINDING

Первый эталонный СБП-плательщик пользователя фиксируется только по первому успешно зачисленному СБП-депозиту. Платежи, которые были возвращены, отклонены или поставлены on hold, не становятся эталонными.

#### SBP\_HIGH\_AMOUNT\_KYC\_THRESHOLD

Если сумма СБП-пополнения в RUB превышает настроенный порог `N`, система запрашивает KYC.

#### SBP\_HIGH\_AMOUNT\_FIRST\_PAYER\_KYC\_HOLD

Если первый СБП-депозит пользователя превышает порог `N`, средства удерживаются до прохождения KYC. При успешном KYC депозит зачисляется, а плательщик привязывается как эталонный. Если KYC не пройден за 1-2 часа, депозит возвращается.

#### SBP\_KYC\_THRESHOLD\_REMOVED\_AFTER\_KYC

Если пользователь прошёл KYC, СБП-депозиты больше `N` больше не требуют KYC по признаку суммы. При этом продолжают применяться тарифные лимиты карты и проверка плательщика.

#### SBP\_DIFFERENT\_PAYER\_REFUND\_AND\_KYC\_BEFORE\_KYC

До KYC, если СБП-пополнение поступило от плательщика, отличающегося от ранее зафиксированного плательщика пользователя, депозит не зачисляется, инициируется возврат, пользователь получает уведомление о необходимости пройти KYC.

#### SBP\_SIXTH\_PAYER\_GRACE\_AND\_RESTRICT

Если после KYC появляется 6-й уникальный СБП-плательщик, депозит ещё зачисляется. После зачисления пользователю включается ограничение: дальнейшие СБП-пополнения разрешены только от KYC-плательщика. Пользователь получает предупреждение.

#### SBP\_RESTRICT\_TO\_KYC\_NAME\_AFTER\_PAYER\_LIMIT

После достижения лимита уникальных плательщиков дальнейшие СБП-депозиты разрешены только если ФИО плательщика совпадает с ФИО, подтверждённым в KYC.

#### SBP\_PAYER\_CHECK\_AFTER\_PAYMENT

ФИО/идентификатор СБП-плательщика становится известен только после фактической оплаты от провайдера. Поэтому payer restriction применяется после `Sbp.PayerObserved`: если плательщик запрещён, платёж не зачисляется и автоматически возвращается.

#### SBP\_DEPOSIT\_RESTRICTION\_MANUAL\_LIFT

Ограничение `sbp_only_kyc_payer_allowed` может быть снято только после проверки. Support только объясняет и эскалирует. Compliance/Admin может снять ограничение с audit log.

***

### Crypto-депозиты

#### CRYPTO\_PROCESSING\_OUTPUT\_STABLES

Независимо от входной криптовалюты/сети, CardApp учитывает результат процессинга как стейбл-актив для дальнейшего зачисления.

#### INTERNAL\_TREASURY\_HANDLES\_CAAS\_FUNDING

Пользовательский депозит учитывается в продуктовой валюте карты, а выбор конкретного стейбла/CaaS-актива и ручное казначейское пополнение — внутренняя операция.

#### CRYPTO\_LATE\_PAYMENT\_CAN\_COMPLETE\_IF\_MATCHED

Если crypto-платёж пришёл после истечения quote, но backend может сопоставить его с заявкой и депозит проходит проверки, процедура завершается и средства зачисляются.

#### UNMATCHED\_CRYPTO\_DEPOSIT\_HELD\_UNTIL\_CLAIMED

Несопоставленный crypto-депозит удерживается как unmatched и не зачисляется, пока отправитель не обратится и не подтвердит принадлежность платежа.

#### UNMATCHED\_CRYPTO\_CLAIM\_STRICT\_REVIEW

Заявка на присвоение unmatched crypto-депозита считается высокорисковой. Пользователь должен предоставить максимум доказательств, а решение принимается только после строгой проверки.

#### UNMATCHED\_CRYPTO\_CLAIM\_FOUR\_EYES

Support собирает данные по unmatched crypto claim, но не принимает решение. Одобрение требует Admin + ControlObserver.

#### CRYPTO\_LATE\_MATCHING\_RETENTION

Система должна хранить данные, необходимые для сопоставления crypto-платежей с заявками, достаточно долго для обработки поздних blockchain-транзакций и поддержки пользовательских обращений. Конкретный retention period задаётся технической и compliance-политикой.

***

### Платежи, 3DS и отказы

#### THREE\_DS\_REQUIREMENT\_SOURCES

3DS-челлендж может быть инициирован провайдером/мерчантом или внутренней risk-логикой платформы.

#### THREE\_DS\_FAILURE\_DECLINES\_AUTHORIZATION

Если пользователь отклонил 3DS или не подтвердил его до истечения таймера, карточная авторизация отклоняется.

#### CARD\_DECLINE\_REASON\_VISIBLE\_TO\_USER

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

#### SUSPICIOUS\_OPERATION\_DECLINE\_ONLY\_V1

В первой версии подозрительная карточная операция только отклоняется. Карта не замораживается автоматически и дополнительный 2FA не запрашивается.

***

### Risk

#### SBP\_RISK\_SIGNALS\_V1

В первой версии фиксируются следующие риск-сигналы по СБП:

* много уникальных плательщиков;
* новый плательщик после ограничения;
* несовпадение с KYC-ФИО;
* частая смена плательщика;
* плательщик связан с несколькими пользователями;
* инструмент связан с несколькими пользователями;
* много failed/refunded/onHold по одному инструменту;
* повтор после отказа/возврата.

#### RISK\_ACTIONS\_V1

В v1 по этим сигналам система копит данные, показывает их в админке, предупреждает пользователя и ограничивает депозиты. Автоматический soft-block по этим сигналам не делается.

#### SBP\_ONLY\_KYC\_PAYER\_RESTRICTION

Ограничение применяется только к СБП-депозитам от новых/чужих плательщиков. Crypto этим правилом не ограничивается.

***

### Support и споры

#### SUPPORT\_NO\_FINANCIAL\_OR\_RESTRICTION\_ACTIONS

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

#### DISPUTE\_ONLY\_FOR\_CLEARED\_TX\_VIA\_SUPPORT

Пользователь может открыть спор только по успешно списанной операции. Открытие и ведение спора происходит через поддержку.

#### AI\_DISPUTE\_INTAKE\_BEFORE\_HUMAN\_ESCALATION

Перед передачей спора оператору AI-ассистент собирает максимум данных: транзакция, причина, описание, доказательства, ожидание пользователя.

#### AI\_NO\_FINAL\_DISPUTE\_DECISION

AI-ассистент не может финально одобрить или отклонить спор. Он только собирает данные, формирует summary и предварительную оценку для оператора.

***

### AI и knowledge base

#### KNOWLEDGE\_BASE\_CHANGES\_REQUIRE\_APPROVAL

Изменения FAQ/Knowledge Base, используемой AI-ассистентом, публикуются только после approval.

#### AI\_GROUNDED\_ANSWERS\_ONLY

AI-ассистент отвечает только на основе опубликованной knowledge base и доступных данных CardApp. Если информации недостаточно, он не придумывает ответ, а предлагает обратиться в поддержку.

#### AI\_ANSWER\_TRACEABILITY

Ответы AI желательно логировать вместе с источниками knowledge base, на которые он опирался, чтобы можно было проводить аудит качества и разбор спорных ответов.

***

### Referral

#### REF\_PROGRAM\_REQUIRES\_OPEN\_CARD

Если пользователь без открытой карты пытается создать реферальную ссылку, система не создаёт код и показывает CTA на открытие карты.

#### REF\_LINK\_AFTER\_CARD\_OPENED

Пользователь может создать реферальную ссылку только после открытия хотя бы одной карты. Ссылка создаётся по явному действию пользователя.

#### REFERRAL\_ACTIVATION\_REQUIRES\_CARD\_AND\_FIRST\_DEPOSIT

Реферал считается активным и даёт право на бонус только после открытия карты и первого депозита.

#### REFERRAL\_REWARD\_RECIPIENTS\_CONFIGURABLE

Получатели и суммы реферального бонуса задаются конфигурацией программы. По текущей гипотезе бонус получают обе стороны.

#### REFERRAL\_PAYOUT\_MIN\_THRESHOLD

Реферальный/бонусный вывод доступен только после накопления $200.

#### REWARD\_TRANSFER\_TO\_CARD\_AFTER\_200\_USD

Бонусный баланс нельзя перевести на карту, пока он меньше $200. После достижения $200 пользователь может запросить перевод бонусов на баланс карты.

#### MANUAL\_REWARD\_TRANSFER

Достижение $200 не переводит бонусы автоматически. Пользователь сам нажимает «перевести на карту».

#### USER\_SELECTS\_REWARD\_TRANSFER\_CARD

При переводе бонусного баланса пользователь выбирает целевую карту из своих открытых карт.

***

### Affiliate

#### AFFILIATE\_REQUIRES\_APPROVAL

Партнёр не получает кабинет и ссылки автоматически. Сначала он подаёт заявку, затем после аппрува получает доступ.

#### AFFILIATE\_APPROVAL\_RBAC

Заявку партнёра может одобрить администратор или affiliate manager. Действие логируется в audit.

#### AFFILIATE\_CUSTOM\_TERMS

Партнёр может иметь индивидуальные условия вознаграждения: фиксированный бонус за активированного пользователя и/или долю от обменной маржи по депозитам.

#### AFFILIATE\_COMMISSION\_ACCRUAL

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

#### AFFILIATE\_MONTHLY\_CUSTOM\_PAYOUTS

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

#### AFFILIATE\_INTERNAL\_TRACKING\_AND\_PARTNER\_POSTBACKS

CardApp самостоятельно трекает партнёрские клики, регистрации и конверсии. Если партнёр настроил Postback API, CardApp отправляет ему postback по разрешённым событиям.

#### AFFILIATE\_POSTBACK\_NO\_RAW\_PII

Партнёрские postback-и не содержат raw PII. Email/телефон передаются только в маскированном виде или через внешний псевдоним пользователя.

#### AFFILIATE\_POSTBACK\_NEAR\_REALTIME

Партнёрские postback-и отправляются near-real-time. Небольшая задержка допустима и не считается ошибкой.

#### AFFILIATE\_POSTBACK\_RETRY\_POLICY

Если партнёрский endpoint вернул `2xx`, postback считается доставленным. Если `408/429/5xx/network timeout`, повторяем с exponential backoff. Если `400/401/403/404`, считаем ошибкой настройки без retry. Максимум 8 попыток, окно retry до 24 часов. После исчерпания попыток — dead letter. Payload подписывается HMAC-secret. Партнёр может выполнить manual retry после исправления настроек.

***

### Уведомления

#### IMPORTANT\_NOTIFICATION\_CATEGORY\_MIN\_ONE\_CHANNEL

Для important=true категорий нельзя отключить все каналы. Минимум один из TG/Email/Push должен быть включён.

#### NON\_IMPORTANT\_NOTIFICATIONS\_CAN\_BE\_FULLY\_DISABLED

Для категорий important=false пользователь может отключить все каналы TG/Email/Push.

#### IMPORTANT\_NOTIFICATION\_CATEGORIES

Важные категории:

* Все транзакции;
* 3DS-запросы;
* Споры;
* Безопасность;
* KYC / Compliance;
* Legal updates;
* Карты.

#### CARD\_NOTIFICATIONS\_ARE\_IMPORTANT

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

#### NOTIFICATION\_CHANNEL\_AS\_PAYLOAD

Канал доставки должен быть атрибутом notification events, а не отдельным event type. Пример каналов: `tg`, `email`, `push`, `in_app`. Это позволяет обрабатывать retries, provider errors и multi-channel delivery единообразно.

#### NOTIFICATION\_TEMPLATE\_CHANGES\_REQUIRE\_APPROVAL

Изменение шаблонов уведомлений требует approval другим оператором/admin по four-eyes.

***

### Refunds и withdrawals

#### REFUND\_SCENARIOS\_V1

В v1 возвраты/выводы возможны для:

* СБП late/mismatch;
* неуспешного или задержанного выпуска карты через support flow;
* закрытия аккаунта через crypto withdrawal;
* положительного исхода спора.

#### REFUND\_APPROVAL\_RULES\_V1

Автоматические СБП-возвраты по late/mismatch выполняются без ручного approval. Все остальные refund/withdrawal операции требуют approval Admin + ControlObserver.

#### AUTOMATIC\_SBP\_REFUNDS\_AUDITED

Автоматические СБП-возвраты не требуют approval, но обязательно логируются и отображаются в админке.

#### WITHDRAWAL\_ONLY\_FOR\_ACCOUNT\_CLOSURE\_V1

В первой версии crypto withdrawal доступен только в сценарии закрытия аккаунта. Обычный вывод средств пользователем не поддерживается.

#### ACCOUNT\_CLOSURE\_WITHDRAWAL\_CRYPTO\_ONLY

При закрытии аккаунта остаток средств можно вывести только через crypto withdrawal.

#### ACCOUNT\_CLOSURE\_WITHDRAWAL\_FOUR\_EYES

Crypto withdrawal при закрытии аккаунта требует подтверждения Admin + ControlObserver.

***

### Ledger, finance и treasury

#### OMNIBUS\_FUNDS\_LEDGER\_ATTRIBUTION

Фактические средства находятся в общих master accounts. Пользовательские и карточные балансы являются ledger-attributed projections, рассчитанными из проводок.

#### MASTER\_ACCOUNTS\_WITH\_USER\_ATTRIBUTED\_LEDGER\_ENTRIES

Денежное движение отражается на master accounts через ledger transactions. Каждая запись имеет привязку к пользователю, карте, партнёру или внутреннему назначению.

#### SEPARATE\_LEDGER\_ACCOUNTS\_BY\_BALANCE\_TYPE

Каждая карта, бонусный баланс пользователя, партнёрский баланс и внутренние treasury/fee accounts ведутся отдельными ledger accounts или ledger attribution dimensions.

#### MANUAL\_ADJUSTMENT\_THROUGH\_LEDGER\_WITH\_APPROVAL

Любая ручная корректировка баланса выполняется только через ledger transaction, с обязательной причиной и approval. Прямое изменение баланса запрещено.

#### FOUR\_EYES\_MANUAL\_ADJUSTMENT

Ручную финансовую корректировку должен подтвердить другой оператор/admin. Создатель не может одобрить собственный adjustment.

#### URGENT\_CAAS\_FUNDING\_ALERT

Если баланс CaaS/card provider недостаточен для обслуживания пользовательских операций, система поднимает срочный алерт. Казначей/admin вручную пополняет провайдера.

#### PROVIDER\_CREDIT\_LIMIT\_BACKSTOP

У card/CaaS provider должен быть кредитный лимит/овердрафт, покрывающий временную нехватку funding. При приближении к исчерпанию лимита система поднимает срочный treasury alert.

#### HIDE\_PROVIDER\_LIQUIDITY\_REASON\_FROM\_USER

Если операция отклонена из-за исчерпания provider funding/credit limit, пользователь видит нейтральную причину: `Service temporarily unavailable`. Внутренняя причина доступна только админам.

***

### AdminPanel, роли и approvals

#### ADMIN\_PANEL\_V1\_ROLES

В v1 доступны роли:

* Admin;
* Support;
* ControlObserver.

ControlObserver имеет read-only доступ и участвует в подтверждении reconciliation/daily close.

#### ADMIN\_RBAC\_EXTENSIBLE

Админка строится на ролях и granular permissions. Модель должна позволять добавлять новые роли, расширять штат и сужать доступы без изменения доменной модели.

#### DEPOSIT\_RESTRICTION\_RBAC

Support не снимает депозитное ограничение, а только объясняет и эскалирует. Снять ограничение могут compliance/admin после проверки, с обязательным audit log.

#### FOUR\_EYES\_FOR\_CRITICAL\_ADMIN\_ACTIONS\_V1

На старте все критичные административные действия требуют approval другим оператором/admin. Позже правило можно сделать конфигурируемым по типу действия и роли.

#### NO\_ADMIN\_FEATURE\_FLAGS\_OR\_SYSTEM\_SETTINGS\_V1

В первой версии админки нет управления feature flags и системными настройками. Эти параметры меняются через технический процесс разработки/конфигурации.

#### FEATURE\_FLAGS\_AND\_SETTINGS\_FUTURE\_SCOPE

Управление feature flags и system settings через админку планируется на будущие версии, но не входит в v1.

#### NO\_BULK\_DATA\_EXPORTS\_V1

В первой версии админки нет массового скачивания баз и raw exports. Данные доступны только в интерфейсе по ролям и правам.

***

### Reconciliation

#### DAILY\_RECONCILIATION\_REQUIRED

Система должна выполнять сверку между master accounts, провайдерами, ledger, projections и процессингами.

#### MANUAL\_RECON\_APPROVAL\_V1

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

#### RECON\_APPROVAL\_ADMIN\_AND\_CONTROL\_OBSERVER\_V1

В первой версии сверка и закрытие дня требуют подтверждения двумя ролями: ControlObserver и Admin.

#### CONTROL\_OBSERVER\_READONLY\_RECON\_APPROVAL

Оператор отдела контроля имеет read-only доступ и может подтверждать результаты сверки как наблюдатель. Он не имеет прав на финансовые или административные изменения.

***

### Legal и privacy

#### LEGAL\_ACCEPTANCE\_BY\_CONTEXT

Общие условия и privacy принимаются при регистрации. Условия тарифа и выпуска карты принимаются при открытии каждой новой карты. Новая версия документа может требовать повторного принятия перед следующим релевантным действием.

#### PII\_MASKED\_BY\_DEFAULT\_INTERNAL\_UI

PII в админке и внутренних интерфейсах скрывается/маскируется по умолчанию. Менеджеры не должны видеть и копировать полные данные пользователей без отдельного разрешения.

#### FULL\_PII\_ACCESS\_REQUIRES\_JUSTIFICATION

Доступ к полным PII требует отдельного действия, причины и audit log.

#### ADMIN\_ONLY\_FULL\_PII\_ACCESS

Полные персональные данные может раскрыть только Admin. Действие требует причины и записывается в audit log.

#### ACCOUNT\_CLOSURE\_REQUIRES\_ZERO\_BALANCE

Аккаунт можно закрыть только после вывода или расходования всех средств. После закрытия данные продолжают храниться в базе в рамках retention/legal/compliance требований.

***

### Future scope / отложено

* MAKS Mini App.
* Feature flags и system settings через админку.
* Массовые exports/raw downloads.
* Точные тарифные лимиты депозитов и оплат.
* Расширенные роли: affiliate manager, finance, compliance.
* Автоматизация reconciliation после стабилизации процессов.
* Детальные retention periods.
* Полная матрица risk scoring за пределами СБП.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://alt3-capital.gitbook.io/funding-arbitrage-strategy/cart/proektnaya-dokumentaciya/service_policies-md.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.