CRM для обменных пунктов и OTC: исчерпывающее исследование модулей и функций

Глубокое исследование: 15 направлений, 15 запланировано. Multi-agent web research.

Executive summary

Что такое CRM для наличного крипто-обменника / OTC-деска

Это не «CRM» в маркетинговом смысле (воронка лидов + email-рассылки), а операционное ядро финансового бизнеса — гибрид CRM + trading back-office + cash-management + compliance-платформы + бухгалтерского леджера. Система обслуживает специфический бизнес: обмен между наличным фиатом (USD/EUR/TRY/UAH/RUB), криптой (TRON/ETH/BTC, преимущественно USDT) и онлайн-каналами, где «домашней» учётной валютой выступает USDT, а физическая касса, on-chain кошелёк и клиентская сделка должны сходиться до цента и до tx-hash.

Принципиальное отличие от обычной CRM в том, что система одновременно держит четыре связанных контура учёта, которые обязаны постоянно сверяться: 1. Сделка (Deal/Quote) — коммерческий слой: что обещали клиенту, по какому курсу, с какой маржой. 2. Наличная касса (Till/Vault/Treasury) — физический слой: покупюрный остаток, смены, инкассация. 3. On-chain кошелёк (Wallet) — блокчейн-слой: реальные движения, подтверждения, газ, sweep. 4. Леджер (double-entry GL) — финансовый слой истины: дебет=кредит, P&L, переоценка.

Поверх этих контуров натянуты сквозные дисциплины: комплаенс (KYC/KYB, AML, Travel Rule, санкции), безопасность (RBAC, maker-checker, аудит-лог), ценообразование (спред-движок) и аналитика (CEO-дашборд, KPI). Связующая логика — сделка (Deal) как агрегат над операциями, с иммутабельной машиной состояний и аудит-трейлом каждого перехода.

Состав системы укладывается в 15 функциональных модулей (см. taxonomy), которые группируются в 5 контуров: (A) Front-office / сделки и клиенты, (B) Money-movement / касса и кошельки, (C) Финансовый учёт / леджер и аналитика, (D) Контроль / комплаенс и безопасность, (E) Платформа / интеграции, коммуникации, регуляторика. Глубина каждого модуля резко зависит от типа оператора: мелкий обменник закрывает 80% задач Google-таблицей и ручным P&L, сеть филиалов нуждается в консолидации и intercompany-элиминации, институциональный OTC-деск — в RFQ-движке, агрегации ликвидности, FIX-интеграциях и SOC 2.

Ключевой вывод по рынку: готового «коробочного» продукта именно под сеть наличных офисов почти нет — средний white-label ($60–100K+) заточен под онлайн-обменники и брокеров, а кассово-мультифилиальный учёт (смены, покупюрная инкассация, фондирование точек) — системно слабое место рынка. Это и оправдывает build для данного бизнеса: дифференциатор лежит в самом движке учёта наличной ликвидности + авто-сверке с блокчейном.

Карта модулей (таксономия)

Единая карта модулей CRM обменника/OTC

15 направлений сгруппированы в 5 контуров. Колонка «Тег» = исходный дайджест.

Контур A — Front-office: сделки и клиенты

Контур B — Money-movement: наличные и крипта

Контур C — Финансовый учёт и аналитика

Контур D — Контроль: комплаенс и безопасность

Контур E — Платформа: интеграции, рынок, регуляторика

Сводная иерархия (компактно)

CRM обменника/OTC
├─ A. Front-office
│   ├─ Сделки и жизненный цикл [deal-lifecycle]
│   ├─ CRM клиентов + KYC/KYB [client-crm-kyc]
│   └─ Коммуникации/боты/портал [comms-bots]
├─ B. Money-movement
│   ├─ Касса и наличная казна [cash-treasury]
│   ├─ Крипто-кошельки/блокчейн [crypto-wallets]
│   └─ OTC RFQ/блок-трейды [otc-workflow]
├─ C. Финучёт и аналитика
│   ├─ Ценообразование/спред [pricing-rates]
│   ├─ Леджер/P&L/сверка [accounting-finance]
│   ├─ Аналитика/BI/KPI [analytics-bi]
│   └─ Партнёры/комиссии [partner-network]
├─ D. Контроль
│   ├─ Комплаенс/AML/Travel Rule [compliance-aml]
│   └─ Безопасность/RBAC/аудит [security-rbac]
└─ E. Платформа
    ├─ Интеграции/API [integrations-api]
    ├─ Ландшафт продуктов [landscape-products]
    └─ Регуляторика [regulatory-jurisdictions]

Как работают разные игроки

Чем различаются операторы по модулям

Три архетипа: мелкий обменник (1-2 точки, владелец = оператор), сеть филиалов (5-50 точек + партнёры/франшиза), институциональный OTC-деск (блок-трейды, VASP-контрагенты, FIX).

Сводный профиль

• Мелкий обменник: 5-6 «живых» модулей (Сделки, Касса, Кошельки, базовый Леджер, минимум Комплаенс/RBAC). Стек = Google Sheets + bot + 1 RPC. Риск — отсутствие сверки и аудита, всё держится на доверии владельцу.
• Сеть филиалов: ~12 модулей, центр тяжести — консолидация, мультифилиальный кассовый учёт, intercompany, партнёрские расчёты, рейтинг менеджеров. Здесь рынок не даёт коробки → build/самопис.
• Институциональный OTC: все 15, но центр тяжести смещён в RFQ/ликвидность/хедж/settlement/комплаенс/аудит; наличная касса почти отсутствует. Закрывается white-label (AlphaPoint/Talos/Finery) либо кастомом $5M+.

Сквозные темы

Сквозные темы, пронизывающие все модули

Это не отдельные модули, а горизонтальные дисциплины, которые должны быть «вшиты» в каждый из 15 направлений с самого начала — ретрофит их позже стоит кратно дороже.

1. USDT как функциональная валюта учёта

Все ноги сделок, кассовые остатки, on-chain движения, P&L и партнёрские расчёты пересчитываются в USDT на момент исполнения. Операционные фиаты (USD>EUR>TRY>UAH>RUB) — presentation-уровень. Это пронизывает: pricing (триангуляция через USDT), cash-treasury (переоценка остатков), accounting (functional vs presentation currency, realized/unrealized FX), analytics (multi-currency reporting). Ошибка в одной точке ломает сверку во всех контурах.

2. Сверка и идемпотентность (reconciliation-first)

Сквозной инвариант «четыре контура сходятся»: Deal ↔ Till ↔ Wallet ↔ Ledger. Реализуется через: идемпотентный upsert по натуральному ключу/tx-hash (защита от двойного учёта/импорта), 3-way reconciliation (source↔subledger↔GL), авто-матчинг скорингом с очередью брейков, сверку до цента при импорте легаси. Пронизывает deal-lifecycle, crypto-wallets, cash-treasury, accounting-finance, integrations-api.

3. Комплаенс как фильтр на пути каждой операции

KYC/KYB, санкц/PEP-скрининг, AML-мониторинг, Travel Rule, on-chain risk-scoring — это не «модуль сбоку», а gating-слой внутри сделки (compliance hold в машине состояний), кошелька (pre-send проверка получателя), клиента (CRR-рейтинг), кассы (AML-пороги structuring), интеграций (approve/hold/reject). Пороги конфигурируются per-jurisdiction (FATF $1000, TR 15k TRY/MASAK, MiCA нулевой TFR в ЕС).

4. Безопасность и разделение полномочий

RBAC scoped по офису/партнёру, SoD-матрицы, maker-checker с тиерными порогами, least privilege — применяются к каждому действию во всех модулях. Особенно критично для cash (dual custody, ротация кассиров против сговора), wallets (multisig M-of-N, policy engine), ledger (override брейков с обоснованием).

5. Иммутабельный аудит и версионирование

Append-only лог с hash-chaining (кто/что/когда/старое→новое), WORM-хранение, retention 5-10 лет, snapshot ответов внешних провайдеров (курсы, AML), версионирование KPI-определений через PR, иммутабельный архив коммуникаций (anti off-channel). Это и комплаенс-требование (SEC 17a-4, MiCA tamper-evident), и операционная защита. Пронизывает буквально всё — каждый переход статуса, каждая правка рейтинга, каждое сообщение.

6. Мультивалютность + мультифилиальность как структурная ось

Разрез офис × валюта × контрагент × смена × кошелёк проходит через chart of accounts, кассовый учёт, аналитику, партнёрские расчёты, RBAC и комплаенс-агрегацию (structuring across офисов). Это первичный «измерительный куб» всей системы.

7. Машина состояний и аудит-трейл переходов

Не только сделка, но и quote (indicative→firm→matched→settled/expired), смена (open→blind close→close), бот-сессия (FSM с idempotency), KYC-статус, риск-рейтинг — все ключевые сущности имеют явные state machines с иммутабельным логом переходов. Это унифицирующий паттерн моделирования.

8. Регуляторная конфигурируемость

Лимиты, холды, пороги отчётности, retention, налоговая база — не хардкод, а конфигурация по юрисдикции (TR 48/72h холды, $3k/день стейблы, UA 18%+5% налог с 2026, US CTR ≥$10k). Дашборд лицензионных дедлайнов (MiCA ~01.07.2026) — сквозной элемент управления.

Фазы внедрения (MVP → институциональный)

Фазы внедрения: MVP → продвинутый → институциональный

Фазировка построена по принципу «сначала контур учёта истины, потом контроль, потом масштаб». Привязана к реальному состоянию проекта obmenka (уже есть Deals/Clients/Shifts, TRON-sync, авто-сверка, CEO-аналитика — это ≈ конец Фазы 1 / начало Фазы 2).

Фаза 0 — Фундамент (предусловие)

Каноническая модель транзакции, USDT как функциональная валюта, идемпотентный upsult по натуральному ключу/tx-hash, версионирование сквозное, базовый RBAC и append-only аудит-лог. Без этого любой следующий модуль накапливает технический долг.

Фаза 1 — MVP (мелкий обменник: «учёт + сверка + дашборд»)

• Сделки: Deal над Operation, базовая машина состояний, ручная прибыль.
• Клиенты: карточка + минимальный KYC, реф-метка.
• Касса: open/close shift, покупюрная декларация, over/short, межкассовые переводы.
• Кошельки: watch-only TRON-sync, raw_blockchain_tx, реальные балансы.
• Сверка: авто blockchain↔deals скорингом, дедуп по tx-hash, очередь расхождений.
• Леджер: упрощённый double-entry или агрегатный P&L, импорт легаси Google Sheets/Excel.
• Аналитика: CEO-дашборд (оборот/прибыль/маржа/средний чек), разрез по офису/менеджеру.
• Коммуникации: клиентский Telegram-бот приёма заявки.
• Цель: закрыть месяц до цента, видеть маржу, не терять сделки. (Проект уже здесь — v0.10.)

Фаза 2 — Продвинутый (сеть филиалов: «масштаб + контроль + партнёры»)

• Ценообразование: матрица наценок (тир×объём×валюта×канал×офис), плавающий курс от резервов, rate-lock c TTL, алерты на отрицательную маржу.
• Касса/казна: фондирование удалённых офисов, cash forecasting, safe/bank drop в GL, лимиты кассира.
• Кошельки: HD-адреса по офисам, sweep в treasury, gas/energy management, address-poisoning защита.
• Партнёры: реестр own/franchise/agent, спред-сплит, statement+акт сверки, net-settlement T+1, consolidated P&L с intercompany-элиминацией.
• Леджер: полноценный субледжер с разрезами, FX-переоценка realized/unrealized, accrued payroll/bonus, AR/AP aging, period close.
• Безопасность: 5 scoped-ролей по офису, maker-checker с порогами, dual custody касса, ротация апруверов, MFA.
• Комплаенс: rule-based мониторинг (structuring/velocity), агрегация across офисов, CRR-скоринг, санкц-скрининг с fuzzy.
• Аналитика: рейтинг менеджеров, план/факт, когорты/churn/RFM, anomaly-алёрты, прогноз оборота.
• Коммуникации: менеджерский бот + мониторинг чатов (anti off-channel), портал клиента, шаблоны RU/TR/UK/EN.
• Цель: управляемая сеть, прибыльность по точкам, защита от внутреннего фрода.

Фаза 3 — Институциональный (OTC-деск: «ликвидность + расчёты + регуляторная зрелость»)

• OTC/RFQ: firm-quotes с TTL, multi-dealer RFQ, last-look, блок-трейды единой ценой, FIX-интеграция.
• Ликвидность/хедж: aggregation CEX/DEX/десков, SOR, авто-хедж (perp/back-to-back), inventory management.
• Settlement: DvP/atomic escrow, netting, T+0…T+3, settlement instructions.
• Кошельки: MPC/HSM, policy engine, multisig M-of-N, proof-of-reserves.
• Комплаенс: двойной стек chain-analytics, Travel Rule IVMS101 (TRP/Notabene), SAR/STR, counterparty VASP DD, EDD self-hosted.
• Леджер: lot-tracking FIFO/HIFO, ASU 2023-08 fair-value, экспорт в NetSuite/SAP, SOC 2.
• Безопасность: hash-chained WORM аудит + якорение, FIDO2, SoD-матрицы, SIEM.
• Регуляторика: VASP/CASP-лицензирование (MiCA ~01.07.2026, TR CMB, MASAK), CTR/LVCTR, agent list, retention 5-10 лет, дашборд лицензионных дедлайнов, ISO 20022.
• Аналитика: TCA, exposure, NIM/OpEx, semantic layer, streaming.
• Цель: блок-трейды, институциональные контрагенты, аудируемость регулятором.

Принцип перехода между фазами

Каждая фаза не выбрасывает предыдущую, а углубляет уже существующие модули (касса → казна → treasury; ручная прибыль → субледжер → lot-tracking; bot-заявка → RFQ → FIX). Compliance и Security растут параллельно на каждой фазе, а не откладываются «на потом» — иначе ретрофит дороже постройки.

Пробелы и риски

Пробелы, риски и что часто забывают

Сверка и учёт

• Незакрытые «брейки» сверки копятся молча — без очереди разбора, классификации и SLA на закрытие они превращаются в неаудируемый хаос. Нужен KPI exception-aging, а не только match-rate.
• Путаница realized/unrealized при FX и крипто-переоценке — частая бухгалтерская ошибка; ASU 2023-08 (fair-value крипты) многие до сих пор не применяют.
• Неучтённые сетевые комиссии (газ/энергия TRON, fee на выводах) — теряются в P&L, искажают реальную маржу. Fee-adjusted матчинг обязателен.
• Долги/депозиты контрагентов учитывают как выручку вместо обязательства → завышение прибыли. Клиентский депозит = liability до оказания услуги.
• Идемпотентность импорта легаси (Google Sheets/Excel с блоками DEPOSIT/Возврат/сводными) — без натурального ключа и сверки контрольных сумм импорт двоит сделки.

Блокчейн

• Fake-deposit атака: чтение /wallet вместо /walletsolidity (неподтверждённые vs финализированные), доверие к Transfer-событию без проверки реального изменения баланса.
• Reorg-обработка: сделку «закрыли» по неподтверждённой транзакции, которая откатилась. Нужно N подтверждений + переоткрытие при reorg.
• Address poisoning: dust-транзакции с похожим адресом → оператор копирует ядовитый адрес. Фильтрация dust, скрытие unverified-токенов, валидация memo.
• Gas-station дилемма: свежий депозитный адрес без TRX/ETH не может sweep'нуться — забывают про дотацию газа.
• Приватные ключи в учётной системе — антипаттерн; должно быть watch-only по xpub + MPC/HSM подпись отдельно.

Комплаенс / регуляторика

• Structuring across офисов/партнёров: клиент дробит операции по точкам, чтобы обойти порог — без агрегации по golden record не ловится.
• Travel Rule sunrise problem: встречный VASP не поддерживает IVMS101 — обмен данными ломается; self-hosted кошельки требуют proof-of-ownership.
• Tipping-off: сотрудник предупреждает клиента о SAR — уголовное нарушение, требует встроенного запрета на уведомление.
• Дедлайны лицензий ползут: MiCA финальный CASP ~01.07.2026, TR CASP с марта 2025, UA-налог с 2026 — без дашборда статусов легко пропустить переходный период.
• Retention 5-10 лет + tamper-evident — часто откладывают «на потом», потом нечем доказать целостность регулятору.

Безопасность / внутренний фрод

• Сговор кассиров (реальный кейс инсайдерского сговора на $200M): без ротации апруверов и dual custody maker-checker обходится сговором двоих.
• Курс хуже стандарта / аномальные отмены / операции вне часов — поведенческие антифрод-сигналы, которые мало кто мониторит.
• Off-channel коммуникации (увод клиента в личку, обещание курса вне системы) — штрафы SEC/CFTC на $2B+; нужен иммутабельный архив и алерты.
• PII в выгрузках/логах без маскирования по роли — утечка паспортов/адресов кошельков.

Архитектура / рынок

• Кассово-мультифилиальный учёт — системная дыра рынка: white-label заточены под онлайн-обменники и брокеров, наличная сеть (смены, покупюрная инкассация, фондирование точек) не покрыта коробкой. Это одновременно и риск (build обязателен), и подтверждение выбора build.
• Build vs buy ловушка: кастом $5M+ / 18-36 мес против 6-14 недель white-label — build оправдан только если дифференциатор в самом движке (для сети наличных офисов — да, в учёте ликвидности).
• Stale rate / отрицательная маржа: без staleness-контроля, circuit breaker и алерта на margin<порог обменник торгует себе в убыток или становится жертвой арбитража клиентом.
• Webhook-надёжность: без HMAC-проверки raw-тела, timestamp-replay-защиты, идемпотентности по event_id и ротации секретов с overlap — двойная обработка или подделка событий.
• Семантический слой KPI: без metrics-as-code (единое определение «маржи», «оборота») разные дашборды показывают разные цифры → потеря доверия к аналитике.

Организационно-процессное

• Period close без чеклиста (лок проводок, начисления, переоценка, trial balance) → нельзя надёжно закрыть месяц.
• Compliance и Security откладывают на «после MVP» — самая дорогая ошибка: ретрофит аудит-лога, RBAC и сверки в работающую систему дороже, чем заложить с Фазы 0.
• Партнёрские расчёты (net-settlement, hawala-неттинг, post-commit accrual) недооценивают по сложности — intercompany-элиминация и сверка statement'ов часто делаются вручную и с ошибками.

Детальные разделы по направлениям

Управление сделками и жизненный цикл транзакции

Кратко: Раздел детально разбирает модуль «Управление сделками и жизненный цикл транзакции» для крипто back-office: от захвата заявки и котировки с lock-rate до частичных исполнений, отмен/возвратов, расчёта и привязки к кассе/кошелькам. Покрыта модель данных (Deal/Quote/Leg/Ticket/Settlement/LedgerEntry), машина состояний сделки, мультивалютность с учётом в USDT, и различия в реализации у мелкого обменника, сети филиалов и институционального OTC-деска с лучшими практиками и рисками.

Управление сделками и жизненный цикл транзакции

Модуль управления сделками — это операционное ядро back-office обменника: он фиксирует намерение клиента, превращает его в исполнимую сделку с зафиксированным курсом, проводит её через стадии исполнения и расчёта и в конце сводит к движению денег по кассам и кошелькам. В отличие от биржевого matching-engine, в обменнике/OTC сделка почти всегда заключается «принципалом» (дом сам выступает контрагентом по своей цене), поэтому центральным артефактом является не ордер в стакане, а котировка (quote) с ограниченным сроком жизни и сделка (deal/ticket) как контейнер всего жизненного цикла.

Что делает модуль

• Захват заявки (order/deal capture). Регистрирует параметры: направление (buy/sell crypto), пара (USDT↔TRY, USD↔USDT, BTC↔USDT), сумма (в give- или get-валюте), канал (касса в Анталье/Аланье, онлайн-OTC через партнёра, фиат-ФОП Украина), клиент, менеджер/партнёр, способ доставки актива (наличные, перевод, on-chain адрес).
• Котирование и фиксация курса (quote / lock-rate). Считает курс из базового рынка + спред/наценка по сегменту клиента, формирует firm-quote с TTL и таймером обратного отсчёта, блокирует исполнение по истёкшей котировке.
• Управление жизненным циклом (ticket lifecycle). Ведёт сделку по машине состояний от черновика до расчёта/архива, фиксируя каждое изменение с меткой времени и автором (audit trail).
• Частичные исполнения, отмены, возвраты. Поддерживает добор сделки по частям, аннулирование до фиксации, и возврат уже принятых средств.
• Привязка к кассе и кошелькам. Каждая нога сделки порождает движение по конкретной кассе (till) или кошельку (on-chain адрес TRON/ETH), что и даёт двойную запись в леджере и сверку.

Котировка и lock-rate: ключевая механика

Поскольку курс крипты волатилен, дом несёт ценовой риск с момента фиксации до момента, когда сам захеджируется или исполнит. Поэтому котировка firm (твёрдая, исполнимая по показанной цене) и имеет жёсткий TTL. На практике разброс огромен:

• Институциональный RFQ / streaming: котировки живут 1–5 секунд (Coinbase Prime: UI 3 сек, refresh до 20 раз; API 1 сек; некоторые маркет-мейкеры — до 2.5 сек). Цена locked, сделка не появляется в публичном стакане до расчёта.
• Розничный обменник / касса: курс фиксируется на 15–30 минут (а для крупных сделок по договорённости — дольше), потому что клиенту физически нужно дойти/довезти наличные.

Хорошая реализация: quote хранит base_rate, markup/spread, final_rate, valid_until, quote_id; при акцепте сервер проверяет now < valid_until атомарно. Двусторонняя котировка (two-way bid/ask) скрывает от клиента направление дома. Истёкшая котировка не исполняется — нужен новый RFQ. Расхождение «show price vs fill price» (slippage) контролируется допуском.

Машина состояний сделки (lifecycle)

Типовой набор статусов, объединяющий OTC- и кассовую практику:

1. Draft / Quoted — заявка собрана, котировка выдана, ждёт акцепта; авто-переход в Expired по TTL.
2. Accepted / Locked — клиент согласился, курс зафиксирован, дом принял ценовой риск; запускаются pre-trade проверки.
3. Compliance hold — KYC/AML/sanctions/PEP-скрининг, проверка лимитов и Travel Rule (см. ниже). Может уйти в Rejected.
4. Awaiting funds — ждём поступления от клиента (наличные в кассу / on-chain входящий перевод). Здесь часто сидят частичные исполнения.
5. Funded / In settlement — средства получены, дом отдаёт встречную ногу.
6. Partially filled — исполнена часть объёма; остаток либо досматривается, либо отменяется (аналог IOC — Immediate-Or-Cancel — где неисполненный хвост гасится).
7. Settled / Completed — обе ноги проведены, леджер сбалансирован.
8. Cancelled — отмена до фиксации/funding (без финансовых последствий).
9. Refunded / Returned — возврат уже принятых средств (минус комиссия/курсовая разница).
10. Failed / Disputed — техническая ошибка, недосыл, спор.

Каждый переход — иммутабельная запись в журнале (кто, когда, причина). Это требование и аудита, и сверки.

Мультивалютность и конвертации

Обменник почти всегда работает в нескольких операционных валютах (USD, EUR, TRY, UAH, RUB), но учётная валюта одна — USDT. Сделка может быть:

• наличные ↔ крипта (TRY cash → USDT on-chain) — две ноги в разных «местах хранения»;
• крипта ↔ крипта (BTC → USDT) — обе ноги on-chain, часто с третьей хедж-ногой;
• фиат ↔ фиат через крипту (UAH ФОП → USDT → TRY cash) — цепочка из нескольких сделок, связанных одним deal-id.

Каждая нога несёт собственную валюту и курс пересчёта в USDT на момент исполнения. Это требует double-entry леджера: на каждую сделку — равные дебет и кредит, балансы всегда сходятся (give-актив уменьшается, get-актив увеличивается). Курсовая разница между фиксацией и исполнением выделяется в отдельную P&L-строку.

Частичные исполнения, отмены, возвраты

• Partial fill. Клиент принёс 60% наличных — сделку дробят: либо порождают связанные дочерние fills с общим parent-deal, либо ведут поле filled_amount/remaining_amount. Остаток рекотируют (курс мог уйти) или гасят.
• Отмена до funding бесплатна и просто меняет статус. После частичного funding отмена превращается в возврат уже принятого.
• Возврат фиксирует курсовую разницу и комиссию как удержание; для on-chain возвратов важна идемпотентность (не отправить дважды) и привязка к исходному tx-hash.

Тикетная система и привязка к кассе/кошелькам

Каждая сделка — это «тикет» с очередью статусов, исполнителем и каналом связи (в рознице — менеджер в Telegram, в OTC — dealer-чат/RFQ-интерфейс). При исполнении система генерирует settlement-инструкции сразу после акцепта (best practice STP — straight-through processing) и привязывает их к конкретной кассе или кошельку. Привязка к on-chain адресу даёт автоматическую сверку: входящий/исходящий tx по адресу матчится со сделкой по сумме/времени/направлению (скоринг-сверка). Многие десятки сделок за день нетятся — multi-trade netting консолидирует расчётные обязательства, уменьшая число фактических переводов.

Как реализуют разные операторы

• Мелкий обменник (1–2 кассы). Часто Excel/Google Sheets или коробочный bureau-de-change софт (Clear View Systems, FXPlus, Moneyexchangesoft). Котировка вручную, lock-rate «на словах», статусы минимальны (открыто/закрыто), сверка кассы в конце смены. Риск — нет иммутабельного журнала и атомарной фиксации курса.
• Сеть филиалов (наш кейс). Своя CRM поверх Deal→Operation: централизованные курсы и спреды, RBAC по ролям, статусная машина, привязка касс и кошельков, авто-сверка blockchain↔deals, дашборды оборота/маржи. Котировка считается из базового курса + наценка по отделению/каналу.
• Институциональный OTC-деск. RFQ-движок (Talos, Finery Markets, Liquid Mercury, FinchTrade), multi-leg packaged quotes (продать BTC, купить ETH+SOL одной котировкой), streaming-цены от 8+ tier-1 ликвидити-провайдеров (B2C2, Cumberland, Wintermute, Jane Street), pre-trade лимиты и credit-checks, post-trade позиции/P&L/exposure в реальном времени, авто-генерация settlement-инструкций и netting.

Лучшие практики

• Атомарная проверка valid_until на сервере при акцепте; никогда не исполнять по клиентской цене без серверной верификации.
• Иммутабельный append-only журнал переходов статусов (audit trail) — основа аудита и сверки.
• Двусторонние котировки и контроль slippage-допуска.
• Идемпотентность on-chain ног (по tx-hash), чтобы не задвоить отправку/импорт.
• Settlement-инструкции — сразу при акцепте (STP), netting в конце дня.
• Связка leg ↔ касса/кошелёк обязательна для авто-сверки.

Типичные ошибки и риски

• Stale-quote execution — исполнение по истёкшему курсу из-за неатомарной проверки TTL → прямой убыток.
• Ценовой риск незахеджированной позиции между Accepted и Settled.
• Потеря средств на частичных исполнениях из-за отсутствия parent/child связи и поля remaining.
• Двойная отправка при возвратах/ретраях (нет идемпотентности).
• Несведённый леджер из-за курса, зафиксированного в разные моменты для двух ног.
• Комплаенс. FATF Travel Rule: порог $/€1000 (US $3000, ЕС — 0), включая «связанные» дроблёные сделки; обязателен sanctions/PEP-скрининг отправителя и получателя до «travel»-передачи данных. Сделка должна уметь вставать на Compliance hold и отклоняться.

Релевантные продукты и стандарты

RFQ/OTC: Talos, Finery Markets, Liquid Mercury, FinchTrade, Coinbase Prime RFQ, GSR. Bureau-de-change: Clear View Systems, FXPlus, CEBS, Calyx, Moneyexchangesoft. Стандарты/регуляции: FATF Recommendation 16 (Travel Rule), FIX-протокол для RFQ, double-entry accounting как инвариант леджера.

Ключевые функции: - Order/deal capture — регистрация заявки с направлением, парой, суммой, каналом, клиентом и способом доставки актива - Quote engine — расчёт курса из базового рынка + спред/наценка по сегменту/отделению - Lock-rate / firm quote с TTL и таймером обратного отсчёта, атомарная проверка valid_until при акцепте - Two-way (bid/ask) котирование, скрывающее направление дома - Multi-leg / packaged RFQ — единая котировка на пакет ног (например sell BTC + buy ETH/SOL) - Машина состояний сделки: Draft→Quoted→Accepted/Locked→Compliance hold→Awaiting funds→Funded→Settled/Cancelled/Refunded/Failed - Иммутабельный audit trail переходов статусов (кто, когда, причина) - Частичные исполнения с parent/child fills и полями filled/remaining, рекотировка остатка - Отмена до funding и возврат (refund) принятых средств с фиксацией курсовой разницы и комиссии - Мультивалютный пересчёт всех ног в учётную валюту USDT на момент исполнения - Double-entry леджер: равные дебет/кредит на сделку, балансировка касс и кошельков - Привязка ноги сделки к конкретной кассе (till) или on-chain кошельку (TRON/ETH) - Авто-сверка blockchain↔deals скорингом по сумме/времени/направлению, дедупликация по tx-hash - Идемпотентность on-chain ног (защита от двойной отправки/импорта) - Генерация settlement-инструкций сразу при акцепте (STP) и multi-trade netting - Pre-trade контроли: credit/position limits, counterparty approval, sanctions/PEP screening - Post-trade контроли: позиции, P&L, статус расчёта, exposure в реальном времени, алерты по лимитам - Compliance hold + Travel Rule: сбор/проверка originator/beneficiary данных при порогах $/€1000 (учёт связанных сделок) - Тикетная система заявок с очередью статусов, исполнителем и каналом связи (Telegram/dealer-чат/RFQ UI) - Расчёт slippage-допуска и контроль расхождения show-price vs fill-price

Источники: - https://www.liquidmercury.com/resources/crypto-otc-desk-software - https://finchtrade.com/blog/understanding-request-for-quote-trading-how-it-works-and-why-it-matters - https://www.cube.exchange/what-is/rfq-request-for-quote - https://docs.cdp.coinbase.com/prime/concepts/trading/rfq - https://www.gate.com/learn/articles/what-is-rfq-crypto-otc - https://www.talos.com/insights/why-rfq-is-essential-in-institutional-crypto-markets - https://finerymarkets.com/rfq.html - https://www.osl.com/en/bits/article/how-to-execute-large-crypto-trades-using-rfq - https://www.g2.com/categories/currency-exchange-bureau - https://www.clearviewsys.com/ - http://monexsoft.com/ - https://usu-tj.com/ru/exchange/programma_dlya_kriptoobmennika.php - https://www.chainup.com/blog/crypto-matching-engine-guide/ - https://finlego.com/blog/designing-a-real-time-ledger-system-with-double-entry-logic - https://sumsub.com/blog/what-is-the-fatf-travel-rule/ - https://amlwatcher.com/blog/fatf-travel-rule/ - https://www.fatf-gafi.org/content/dam/fatf-gafi/recommendations/Best-Practices-Travel-Rule-Supervision.pdf - https://wctpay.com/post/otc-crypto-desks-for-enterprise-price-lock-and-same-day-settlement

CRM клиентов/контрагентов, онбординг, KYC/KYB, сегментация

Кратко: Раздел детально разбирает модуль «CRM клиентов/контрагентов» для back-office крипто-обменников и OTC-десков: карточка клиента и контрагента, онбординг и KYC/KYB, документы, источники привлечения и реферальная атрибуция, сегментация/тиринг, скоринг риска (AML CRR-модель), LTV-история, дедупликация (golden record) и связи клиент↔партнёр. Показано, как это реализуют разные операторы — от мелкого кэш-обменника до сети филиалов и институционального OTC-деска — со ссылками на стандарты (FATF Travel Rule, MiCA) и вендоров (Sumsub, AMLBot, TRM, Moody's Passfort, Data Ladder).

CRM клиентов/контрагентов, онбординг, KYC/KYB, сегментация

Что делает модуль

CRM клиентов/контрагентов — это «золотая запись» (Customer 360 / golden record) каждого физлица и юрлица, с которым у бизнеса есть денежные отношения, плюс операционный хаб, связывающий привлечение, онбординг, комплаенс и сделки. В современном back-office (2026) CRM перестаёт быть адресной книгой и становится слоем, который соединяет acquisition → onboarding → KYC/AML → payments → trading data → IB/affiliate в одном месте. Для крипто-обменника модуль обслуживает три разных типа контрагентов с разными требованиями: розничный клиент кассы (cash-in/cash-out), институциональный OTC-контрагент (другой деск, мерчант, VASP) и внутренний/внешний партнёр-агент, приводящий поток. Карточка хранит идентичность, верификационный статус, риск-профиль, историю сделок, агрегаты (оборот/маржа/LTV) и графовые связи (клиент↔партнёр, UBO↔юрлицо, дубликаты↔мастер).

Ключевые функции (детально)

• Карточка клиента (физлицо): ФИО/имя, дата рождения, гражданство и резидентство, контакты (телефон/email/Telegram), документ (паспорт/ID), фото/селфи-liveness, привязанные кошельки и банковские реквизиты, статус KYC (none/basic/full/EDD), риск-рейтинг, тег сегмента/тира, источник привлечения, привязанный партнёр, история операций и расчётные метрики (оборот, средний чек, маржа, LTV, recency).
• Карточка контрагента (юрлицо/OTC/VASP): регистрационные данные (certificate of incorporation, юрисдикция, рег.номер), UBO/бенефициары (≥25%) с их собственным KYC, authorized signatories, лицензии (VQF/MiCAR/BitLicense), source-of-funds/source-of-wealth, торговое соглашение, API-доступы, лимиты и markup, «expected profile» (ожидаемый паттерн активности для последующего transaction monitoring).
• Онбординг-воркфлоу с тирами верификации: прогрессивный профайлинг — fast path для low-risk (минимальный KYC), доп. AML/sanctions для medium, EDD/ручной ревью для high. Розница individual ~24–48 ч, institutional 3–5 дней / 1–3 недели.
• KYC-верификация: сбор identity-данных, document verification (OCR + проверка подлинности), biometric/liveness, проверка адреса (proof of residence).
• KYB-верификация: registry lookup, UBO-mapping, проверка структуры собственности, лицензий, sanctions/PEP юрлица и бенефициаров.
• Скрининг: sanctions (OFAC/EU/UN), PEP, adverse media; для крипто — on-chain screening привязанных кошельков (связи с миксерами/санкционными адресами) через TRM/Elliptic/Chainalysis.
• Source-of-funds/wealth: обязательно для крупных стейблкоин-объёмов; документальное подтверждение.
• Скоринг риска клиента (CRR): взвешенная модель из 10–20 факторов (customer/geography/product/channel) → итоговый рейтинг low/medium/high, триггеры EDD.
• Сегментация и тиринг: VIP/whale vs regular vs retail; разные liquidity pools, markup, лимиты, торговые условия по тиру.
• Реферальная атрибуция: уникальная ссылка/промокод/метка/договор, привязка клиента к партнёру, first-touch или multi-touch модель, автоначисление бонуса при оплате.
• Дедупликация / identity resolution: exact + fuzzy + phonetic matching, survivorship-правила, golden record.
• LTV и история: агрегация оборота, маржи, частоты; RFM-сегменты; lifecycle-стадии.
• Ongoing monitoring & periodic review: перепроверка по риск-классу (low — ежегодно/раз в 2 года, medium — раз в полгода/год, high — ежеквартально и чаще).
• Аудиторский след: кто/когда менял статус, документы, рейтинг (immutable log).
• Связи клиент↔партнёр↔UBO: граф отношений для атрибуции и комплаенса.

Модель данных (сущности)

Customer (физлицо) / Counterparty (юрлицо) — общая абстракция Party с типом. Связанные: Document (тип, номер, файл, статус, expiry), Wallet/BankAccount, KycCase/KybCase (статус, тир, проверки, ревьюер), ScreeningHit (sanctions/PEP/adverse), RiskRating (score, факторы, дата, ревью-дата), Segment/Tier, AcquisitionSource, ReferralAttribution (partner_id, model, дата), Partner/Agent, UBO (link юрлицо→физлицо, % доли), DuplicateLink (candidate→master, score), агрегаты LTVSnapshot. Связь с операционным слоем — через Deal/Operation.

Основные рабочие процессы

1. Онбординг розничного клиента кассы: заведение карточки → базовый KYC (документ + селфи при превышении порога) → sanctions/PEP скрин → авто-риск-рейтинг → если low — обслуживание, если high — EDD/отказ.
2. Онбординг OTC-контрагента: KYB (incorporation, UBO, sanctions) → source-of-funds → trading agreement + API → тестовая сделка → присвоение тира/лимитов/markup.
3. Привязка к партнёру: клиент пришёл по ссылке/промокоду → фиксация атрибуции → начисление вознаграждения партнёру при первой/повторной сделке.
4. Periodic review: по риск-классу система поднимает кейс на переверификацию.

Как реализуют разные операторы

• Мелкий кэш-обменник: часто Google Sheets / Telegram + минимальная карточка, KYC «по порогу» и по чутью; риск — отсутствие дедупликации и audit trail, фрагментация данных по кассам. Минимально достаточный шаг — единая карточка с тегом источника и базовым sanctions-чеком.
• Сеть филиалов (Анталья/Аланья + онлайн + UA-ФОП): общий golden record поверх касс, дедупликация между офисами (один клиент в трёх кассах = одна карточка), атрибуция к партнёрам, единый риск-движок. Здесь критична identity resolution: матчинг только по точным полям теряет 30–40% дублей, нужны phonetic/edit-distance.
• Институциональный OTC-деск: полноценный KYB с UBO-mapping, source-of-funds для крупных стейблкоин-потоков, сегментация по liquidity pools и markup, counterparty risk (платёжеспособность, сегрегация средств, аудиты), Travel Rule due diligence на встречные VASP. Используют Sumsub/Moody's Passfort/AMLBot для онбординга и TRM/Elliptic для on-chain.

Лучшие практики

• Risk-based, тиринг верификации: friction только там, где есть риск.
• «Expected profile» при онбординге → база для transaction monitoring.
• Перпетуальный KYC (event-driven re-review), а не только периодический.
• Golden record с survivorship-правилами; дедуп до загрузки в продакшн.
• Полный audit trail и разделение ролей (maker/checker) на смене статусов.

Типичные ошибки и риски

• Неверный порог EDD (PEP получает 10/10, но EDD триггерится только при ≥8 в др. сценарии → пропуск).
• Отсутствие дедупликации → размазанный LTV, обход лимитов через «нового» клиента (smurfing).
• Атрибуция «по последнему клику» там, где нужен first-touch — искажает выплаты партнёрам.
• Generic KYC/AML-политика без учёта мульти-юрисдикции (US >$10k → IRS; EU предлагает флаг >€1000 для unhosted wallets).
• Игнор Travel Rule: с июня 2025 FATF переписал Rec.16 — добавлены fraud prevention, CoP, ISO 20022.

Стандарты и регуляции

FATF Travel Rule (Rec.16, порог USD/EUR 1000, ред. июнь 2025), MiCA (ЕС), требования KYB на встречные VASP. Вендоры: Sumsub, AMLBot, KYC-Chain, iDenfy, Persona, Moody's Passfort (онбординг/скоринг); TRM Labs, Elliptic, Chainalysis (on-chain/VASP screening); Data Ladder, WinPure, Redpoint (entity resolution/дедуп); FXBackOffice, Syntellicore, TradeCore (брокер-CRM с встроенным KYC).

Ключевые функции: - Карточка клиента (физлицо): идентичность, документы, кошельки, KYC-статус, риск-рейтинг, источник, LTV - Карточка контрагента (юрлицо/OTC/VASP): incorporation, UBO/бенефициары, signatories, лицензии, expected profile - Онбординг-воркфлоу с тирами верификации (fast path low-risk → EDD/ручной ревью high-risk) - KYC-верификация: OCR документа, проверка подлинности, biometric/liveness, proof of residence - KYB-верификация: registry lookup, UBO-mapping, проверка структуры собственности и лицензий - Sanctions/PEP/adverse media скрининг (OFAC/EU/UN) + on-chain screening привязанных кошельков - Source-of-funds / source-of-wealth для крупных стейблкоин-объёмов - Скоринг риска клиента (CRR): взвешенная модель 10-20 факторов customer/geo/product/channel - Сегментация и тиринг: VIP/whale vs regular vs retail с разными лимитами, markup, liquidity pools - Реферальная атрибуция: уникальная ссылка/промокод/метка, привязка клиент↔партнёр, авто-начисление бонуса - Дедупликация / identity resolution: exact + fuzzy + phonetic matching, survivorship, golden record - LTV и история: агрегация оборота/маржи/частоты, RFM-сегменты, lifecycle-стадии - Ongoing monitoring и periodic review по риск-классу (low ежегодно, high ежеквартально) - Триггеры EDD и эскалация на ручной ревью при высоком риске - Travel Rule due diligence: KYB встречных VASP, сбор/верификация originator-beneficiary, CoP - Граф связей клиент↔партнёр↔UBO↔дубликаты для атрибуции и комплаенса - Аудиторский след (immutable log) и maker/checker на смене статусов и рейтингов - Управление документами: типы, expiry, статусы, перезапрос по истечении - Trading agreement / API-онбординг и тестовая сделка для OTC-контрагента - Назначение лимитов, markup и торговых условий по тиру клиента

Источники: - https://fxbackoffice.com/integrations/kyc - https://blog.amlbot.com/crypto-kyb-business-verification-vasps/ - https://fxnewsgroup.com/forex-news/cryptocurrency/crypto-exchange-xbo-com-selects-sumsub-kyc-kyb-onboarding-and-compliance-solution/ - https://idenfy.com/blog/best-kyc-providers/ - https://kyc-chain.com/what-is-kyc-in-crypto-kyc-crypto-why-exchanges-must-comply-in-2025/ - https://withpersona.com/guides/18-kyc-tactics-crypto - https://www.trmlabs.com/resources/blog/best-vasp-screening-and-risk-assessment-software-2026-buyers-guide - https://www.moodys.com/web/en/us/kyc/products/passfort.html - https://blog.voveid.com/kyb-compliance-in-crypto-a-2025-guide-for-exchanges-and-wallets/ - https://dataladder.com/best-entity-resolution-software/ - https://www.digitalapplied.com/blog/crm-data-deduplication-merge-framework-2026-methodology - https://finchtrade.com/blog/crypto-otc-desk-onboarding-what-institutional-investors-need-to-know - https://www.bitget.com/academy/crypto-otc-desk-guid - https://www.zigram.tech/customer-risk-rating-aml/ - https://www.azakaw.com/blog/customer-risk-rating - https://amlyze.com/aml-risk-scoring/ - https://sumsub.com/blog/what-is-the-fatf-travel-rule/ - https://www.fatf-gafi.org/content/dam/fatf-gafi/recommendations/Best-Practices-Travel-Rule-Supervision.pdf - https://www.primegate.io/calltracking/multichannel-attribution - https://okocrm.com/blog/referalnaya-programma/

Касса, хранилище, наличная ликвидность, мультивалютная казна

Кратко: Модуль «Касса, хранилище, наличная ликвидность, мультивалютная казна» — это учётный и контрольный контур, охватывающий жизненный цикл физических денег: открытие/закрытие кассовых смен с декларацией стартового остатка и подсчётом по номиналам, мультивалютные кассы с покупюрной разбивкой, межкассовые/кассо-сейфовые переводы (двусторонние, с обязательной сверкой), инкассацию в сейф и банк, лимиты кассира и казначейское управление наличной ликвидностью сети офисов. Зрелые реализации (D365 Commerce, CurrencyXchanger/FXOffice для bureau de change) строят его на «двусторонних» транзакциях с подотчётностью каждого движения, X/Z-отчётах, расчёте overage/shortage и казначейской позиции по каждой валюте (holding cost, long/short, break-even). Для крипто-обменника специфика — учёт в USDT как «домашней» валюте при нескольких операционных фиатах, AML-пороги (EU/Turkey MASAK) и фондирование удалённых офисов/партнёров.

Касса, хранилище, наличная ликвидность, мультивалютная казна

Что делает модуль

Это «физический» учётный контур, отвечающий за то, чтобы каждая банкнота имела владельца, источник и след. Он связывает три уровня хранения денег — касса (till/drawer) у конкретного кассира, сейф/хранилище (safe/vault) офиса и казна (treasury) сети — и обеспечивает: подотчётность (accountability), сводимость остатков (reconciliation), контроль лимитов и расчёт казначейской позиции по каждой валюте. В отличие от «сделочного» модуля (купля/продажа крипты), здесь учитываются не сделки, а движения наличности: внесения, изъятия, переводы, инкассация, фондирование. Для крипто-обменника с учётом в USDT касса — это место, где фиат (USD/EUR/TRY/UAH/RUB) физически входит и выходит, а USDT выступает «домашней» мерой стоимости позиции.

Ключевые функции (детально)

1. Кассовая смена (shift). Смена — это совокупность транзакций между «открыть» и «закрыть». При открытии кассир декларирует стартовый остаток (declare start amount) — обычно покупюрно, по каждой валюте. При закрытии выполняется tender declaration (пересчёт фактического остатка), система сравнивает ожидаемое с фактическим и считает overage/shortage (излишек/недостача). Формируется Z-отчёт (финализация смены) и в течение дня — X-отчёт (промежуточный срез без закрытия). Модели смен: fixed till (касса жёстко привязана к терминалу), floating till (смену можно приостановить/перенести на другой терминал), single-user (максимум подотчётности — один ответственный) vs multiple-user, shared shift (одна смена/один лоток на несколько устройств — типично для мобильных). Промежуточный статус blind close позволяет освободить терминал, не пересчитывая кассу немедленно: пересчёт и закрытие делаются позже, возможно другим человеком.

2. Мультивалютная касса и номиналы. Зрелые системы (D365 с v10.0.38, CurrencyXchanger) ведут cash declaration — справочник поддерживаемых номиналов по каждой валюте — и считают остаток как сумму по валютам (start amount = Sum). Подсчёт идёт покупюрно (denomination count), отдельной транзакцией на валюту для start/float/remove, но tender declaration умеет записывать сразу все валюты. Teller-proofing (внутри- и конец-дня) — это сверка покупюрного факта против системного баланса по каждой валюте. Номинальная разбивка критична: при выдаче сдачи и инкассации нужно знать не только сумму, но и структуру купюр (нехватка мелких/ходовых номиналов — частая операционная боль).

3. Внесения/изъятия и межкассовые переводы. Float entry — внесение наличных в лоток (например, доложить размен), tender removal — изъятие. Лучшая практика — двусторонние (two-sided) транзакции с трассировкой: изъятие из кассы A должно быть «принято» внесением в кассу B, и две операции взаимно сверяются (автоматически при выборе встречной транзакции, иначе — ручная reconciliation). Это даёт «cash traceability»: незакрытых (unreconciled) движений быть не должно — смену нельзя закрыть, пока они есть.

4. Инкассация: сейф и банк. Safe drop — изъятие из кассы в сейф офиса (срабатывает при превышении лимита наличных в лотке); bank drop — подготовка к сдаче в банк. Сейф управляется через выделенную смену на отдельном терминале (не используемом для продаж): по нему так же декларируется стартовый остаток, делаются float/removal и tender declaration. Остаток в сейфе не переносится автоматически на следующий день — старший менеджер декларирует его заново. Движения проводятся в соответствующие GL-счета (safe-drop GL, bank-drop GL).

5. Лимиты и пороги. Лимит наличных в лотке (drawer limit) триггерит safe drop; лимиты кассира по сумме сделки/смены; пороги срабатывания AML. В ЕС — единый порог €10 000 для наличных (AMLR 2024/1624, AMLD6); в США — CTR при $10 000. В Турции (yetkili müessese под надзором MASAK) с 01.01.2026 — заявление о цели операции свыше 200 000 TL и обязательная форма декларации наличной операции свыше 2 000 000 TL; подозрительные/необычные операции — порог внимания 75 000 TL. Модуль должен ловить и structuring/smurfing (дробление под порог).

6. Казначейская позиция и ликвидность. Поверх остатков — управление наличной ликвидностью: по каждой валюте система считает long/short position (избыток/нехватка валюты), holding cost (стоимость удержания позиции), average buy rate, break-even rate, COGS и exposure к курсовому риску. Это связывает «физический» модуль с FX-риском: bureau de change зарабатывает на спреде (купил €1.40/£, продал €1.60/£), но несёт риск, если держит дешевеющую валюту. Фондирование офисов — пополнение удалённых точек/партнёров наличностью или USDT-переводом с последующим обналом; депозиты собственника — внесение учредителем оборотного капитала (отдельная сущность движения, влияющая на остаток, но не на P&L).

Сущности данных (модель)

• CashLocation / Account: till, safe, branch-vault, treasury — иерархия хранилищ, каждая с валютным балансом.
• Shift: register, drawer, user(s), статус (open/suspended/blind-closed/closed), start_amount, declared_amount, over_short, X/Z-номера.
• CashMovement / Tender transaction: тип (float_entry, tender_removal, safe_drop, bank_drop, transfer, owner_deposit, funding), сумма, валюта, denomination breakdown, source/destination location, reconciliation_status, linked_txn_id.
• DenominationCount: валюта × номинал × количество (для start/declare/proofing).
• CurrencyPosition: валюта, остаток, avg_buy_rate, holding_cost, long/short, exposure, переоценка в USDT.
• CITOrder / Deposit: инкассация (перевозчик, маршрут, страховой лимит), банковский депозит.

Рабочие процессы

1. Открытие дня: менеджер декларирует остаток сейфа → выдаёт кассирам стартовые суммы (tender removal из сейфа ↔ declare start amount в кассе, авто-сверка).
2. В течение дня: сделки, при нехватке размена — float между кассами; при превышении лимита — safe drop.
3. Закрытие: покупюрный пересчёт → tender declaration → расчёт over/short → blind close → менеджер сводит сейф, делает bank drop, закрывает смены, печатает Z.
4. Сверка end-of-day: Z-отчёт vs системный statement; расхождения объясняются (additional/fewer transactions) — это норма, но недостачи эскалируются.

Как реализуют разные операторы

• Мелкий обменник: одна-две кассы, часто Excel/тетрадь или лёгкий POS (CurrencyXchanger PoS edition); teller-proofing вручную, сейф = физический ящик, инкассация в банк лично.
• Сеть филиалов: централизованная казна, fixed/floating till на терминал, обязательная двусторонняя трассировка, выделенный safe-register, CIT-перевозчик (Brink's/G4S) для инкассации, cash forecasting для оптимизации фондирования (Fiserv заявляет сокращение запасов наличности на 20–40%).
• Институциональный OTC-деск: меньше «лотков», больше казначейства — позиция по валютам в реальном времени, лимиты экспозиции, неттинг между офисами/партнёрами, переоценка в базовой валюте (для крипто-деска — USDT).

Лучшие практики

• Two-sided transactions для всех перемещений — никакой наличности «в воздухе».
• Blind close для скорости + независимый пересчёт менеджером (разделение обязанностей).
• Покупюрный учёт по каждой валюте, а не только суммовой.
• Single-user shift там, где важна подотчётность; жёсткие лимиты лотка и авто-триггер safe drop.
• Ежедневная переоценка валютных остатков в домашней валюте (USDT) + мониторинг long/short и holding cost.
• Сегрегация: касса ≠ сейф ≠ казна; safe-register не делает продаж.

Типичные ошибки и риски

• Незакрытые (unreconciled) переводы между кассами → «теряются» при закрытии смены.
• Учёт только суммы без номиналов → нехватка размена, скрытые недостачи.
• Перенос остатка сейфа «по памяти» вместо ре-декларации → накопление расхождений.
• Игнор AML-порогов и structuring → штрафы (EU AMLR, MASAK CTR-форма).
• Идл-кэш: избыточная наличность в офисах (упущенная доходность, риск кражи) vs кассовые разрывы — баланс через forecasting.
• Курсовой риск незахеджированной long-позиции по слабеющей валюте.
• Инкассация: превышение страхового лимита перевозчика (часто бронемашина обязательна свыше ~$100k).

Продукты / стандарты / регуляции

Софт: Dynamics 365 Commerce (shift/drawer/safe, cash traceability), CurrencyXchanger/CXR (Clear View Systems), Datasoft FxOffice, Calyx, Moneyexchangesoft, Fiserv Cash Optimization. CIT: Brink's, G4S, Loomis; ATMIA CIT Best Practices. Регуляции: EU AMLR (Reg. 2024/1624) / AMLD6 — €10k; US BSA CTR — $10k; Turkey MASAK (yetkili müessese) — 75k/200k/2M TL пороги 2026; UK FCA/Central Bank регистрация bureaux de change.

Ключевые функции: - Открытие/закрытие кассовой смены (open/close shift) с генерацией X- и Z-отчётов - Declare start amount — декларация стартового остатка покупюрно по каждой валюте - Tender declaration — пересчёт фактического остатка при закрытии и расчёт overage/shortage - Blind close — промежуточное закрытие смены без немедленного пересчёта - Модели till: fixed / floating / single-user / multi-user / shared shift - Float entry / tender removal — внесение и изъятие наличных из лотка - Двусторонние межкассовые переводы с авто/ручной сверкой (two-sided cash traceability) - Safe drop — инкассация из кассы в сейф офиса при превышении лимита лотка - Bank drop — подготовка и проводка банковского депозита в GL-счета - Управление сейфом через выделенную смену на отдельном (не-продажном) терминале - Мультивалютная cash declaration: справочник номиналов и покупюрный подсчёт по USD/EUR/TRY/UAH/RUB - Teller-proofing — внутри- и конец-дня сверка покупюрного факта против системного баланса - Лимиты кассира и лотка (drawer limit) с авто-триггером инкассации - Контроль AML-порогов (EU €10k, MASAK 75k/200k/2M TL) и детекция structuring/smurfing - Казначейская позиция по валюте: long/short, holding cost, avg buy rate, break-even, COGS, exposure - Переоценка валютных остатков в домашней валюте (USDT) для крипто-обменника - Фондирование удалённых офисов/партнёров и учёт депозитов собственника - Cash forecasting и оптимизация наличной ликвидности сети (минимизация idle cash) - Интеграция с CIT/инкассаторами: маршруты, страховые лимиты, бронетранспорт - Финансовая сверка смены: Z-отчёт vs централизованный statement с объяснением расхождений

Источники: - https://learn.microsoft.com/en-us/dynamics365/commerce/shift-drawer-management - https://learn.microsoft.com/en-us/dynamics365/commerce/cash-mgmt - https://www.clearviewsys.com/currencyxchanger-pos-edition - https://clearviewsys.screenstepslive.com/s/manuals/m/User_Manual/l/225896-teller-proofing - https://currencyxchanger.com/ - https://en.wikipedia.org/wiki/Bureau_de_change - https://en.wikipedia.org/wiki/Cash-in-transit - https://www.fiserv.com/en/solutions/insights-and-optimization/cash-and-logistics/cash-forecasting-and-optimization.html - https://pmc.ncbi.nlm.nih.gov/articles/PMC3755815/ - https://www.karenaudit.com/en/turkiye-introduces-strict-new-masak-regulations-mandatory-transaction-declarations-for-cash-and-electronic-transfers-above-200000-tl-effective-1-january-2026/ - https://www.sanctionscanner.com/blog/new-masak-financial-crimes-and-compliance-regulations-in-turkey-373 - https://amlnetwork.org/aml-glossary/threshold-reporting/ - https://www.frbservices.org/financial-services/cash/ - https://datasoft.global/platform/fx-dealing-platform/

Крипто-кошельки и блокчейн-интеграция

Кратко: Раздел детально разбирает модуль «Крипто-кошельки и блокчейн-интеграция» для финтех/крипто back-office: hot/cold/warm-архитектуру с HSM и MPC, генерацию и менеджмент депозитных адресов по офисам через HD-деривацию, мультичейн-мониторинг (TRON/ETH/BTC), авто-сверку on-chain↔сделки, управление газом/энергией, защиту от address poisoning и казначейство в USDT. Покрыты конкретные цифры (комиссии TRC20 $0.30–1.00, энергия 32–70k, 27 SR, блок 3с, реорг-глубины), реализации у мелкого обменника vs сети филиалов vs институционального OTC-деска, вендоры (Fireblocks/BitGo/TRM/Chainalysis) и типичные ошибки (fake deposit, чтение /wallet вместо /walletsolidity).

Крипто-кошельки и блокчейн-интеграция

Модуль — это «мост» между внутренним учётом (сделки, смены, клиенты) и реальным состоянием активов в блокчейне. Он отвечает за хранение приватных ключей, генерацию адресов для приёма средств, отслеживание входящих/исходящих транзакций, привязку их к сделкам и поддержание актуальных балансов казначейства. Для сети наличных обменников с учётом в USDT это критический контур: именно здесь сходятся (или расходятся) «бумажный» учёт кассира и фактическое движение монет on-chain.

Что делает модуль

• Custody (хранение ключей): управляет тем, где и как лежат приватные ключи — hot (онлайн, для частых выплат), warm (полу-онлайн, оперативный буфер) и cold (офлайн, основной резерв). Современный подход — «temperature-agnostic» казначейство, динамически распределяющее активы между уровнями.
• Address management: генерирует и закрепляет депозитные/выплатные адреса за офисами, кассирами, клиентами или сделками.
• On-chain monitoring: непрерывно индексирует блоки, ловит входящие зачисления и исходящие списания по контролируемым адресам.
• Reconciliation: сопоставляет on-chain транзакции с записями сделок/смен, флагует расхождения.
• Treasury & balances: агрегирует балансы по чейнам/офисам, делает sweeps в центральный кошелёк, считает доступную ликвидность.
• Risk/Compliance: скрининг адресов на санкции/миксеры/даркнет, защита от address poisoning и fake-token.

Ключевые функции (детально)

1. Hot/Cold/Warm и модель ключей. Базовый выбор: single-key (seed-фраза) vs multisig vs MPC vs HSM. - Мелкий обменник: один-два hot-кошелька (Trust/TronLink) + аппаратный Ledger как cold. Дёшево, но единая точка отказа. - Сеть филиалов: MPC-кошельки (Fireblocks/BitGo/Cobo/Utila) с policy engine — ключ распределён по shares, ни одна сторона не держит целиком; warm-уровень для оперативных выплат, cold-vault для резерва. - Институциональный OTC-деск: HSM (FIPS 140-2/3) для cold + MPC поверх для распределённого подписания. HSM держит до ~10 000 tx/s против ~20 tx/s у чистого MPC, но MPC устраняет single point of compromise — отсюда гибрид «ключи в HSM, подпись через MPC».

2. Генерация адресов (HD-деривация). По BIP32/39/44: m/purpose'/coin_type'/account'/change/address_index (например m/44'/195'/0'/0/0 для TRON, coin_type 60 для ETH). Это даёт детерминированную выдачу адресов из одного seed и watch-only через extended public key (xpub) — учётная система генерит адреса приёма, не касаясь приватных ключей. Практика для обменника: выделять account' под офис (Анталья=0, Аланья=1, онлайн=2), а address_index инкрементить под каждую сделку/клиента — это резко упрощает сверку (адрес → офис → сделка).

3. On-chain мониторинг входящих. У TRON нет нативного event-subscription — production-мониторинг строится на последовательном опросе getblockbynum и фильтрации по контракту USDT (TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t) и сигнатуре transfer (a9059cbb). Блок — каждые 3 секунды, 27 Super Representatives, 2000+ tx/s. Важнейшая ошибка операторов: читать /wallet (включает неподтверждённые) вместо /walletsolidity (финализированные) — отсюда «пропавшие» или фантомные зачисления. Для ETH/ERC-20 — слушать Transfer-события по адресу контракта + проверять transaction.from/event.address, учитывать internal transactions и fake deposit vulnerability (контракт возвращает success без фактического перевода — нужно проверять реальное изменение баланса, а не только статус tx).

4. Подтверждения и реорги. Перед зачислением в учёт ждать N подтверждений: TRON финализируется через solidity-блоки (~19 блоков/~57с до необратимости), ETH — обычно 12+ блоков (после Merge — ориентир на finalized), BTC — 1–6. Модуль должен переоткрывать сделку при reorg.

5. Газ/комиссии и Energy/Bandwidth. TRC20-перевод требует ~32 000–70 000 Energy. Со стейкнутым TRX — доли цента; без ресурсов — $0.30–$1.00 сгораемого TRX. Best practice: wallet/estimateenergy перед broadcast + буфер ~10% к fee_limit (конгестия может поднять реальный расход). Три способа получить ресурс: стейкинг TRX, аренда энергии на маркетплейсе (дешевле всего при объёме), или burn per-tx. Для ETH — управление nonce и gas (EIP-1559 base+priority fee), «gas station»-кошелёк, который дотирует TRX/ETH на свежие депозитные адреса перед sweep.

6. Sweeps и казначейство. Средства с множества депозитных адресов «сметаются» в центральный treasury-кошелёк (по расписанию/порогу). Для обменника: ночной sweep остатков офисов в cold-резерв, поддержание hot-буфера под дневные выплаты. Балансы агрегируются по чейнам/офисам в едином дашборде с real-time visibility.

7. Авто-сверка on-chain↔сделки. Движок матчит транзакции с леджером по направлению/активу/сумме/времени/адресу — one-to-one, one-to-many и many-to-many (одна выплата покрывает несколько сделок). Расхождения (есть on-chain, нет сделки — и наоборот) попадают в очередь разбора. Чистый паттерн: вести subledger крипто-движений и постить агрегаты в главную книгу.

8. Защита от address poisoning / fake-token. Атака: дастинг (<$0.01 TRX) с vanity-адресов, визуально похожих на реальные, + fake-токены с фишинг-ссылками в memo. Масштаб промышленный: один адрес делал ~4800 AccountCreateContract, ~920 исходящих дастов. Защита оператора: фильтровать/прятать dust-уровневые переводы в UI, не показывать неверифицированные токены, валидировать memo-поля перед отображением, белый список выплатных адресов (whitelisting в policy engine), обязательная проверга первых/последних символов и сверка контракта токена с эталонным. В 2024–2025 USDT-TRC20 — главная мишень из-за дешёвых комиссий.

9. Compliance-скрининг. Интеграция с Chainalysis / TRM Labs / Elliptic: скоринг входящего адреса (миксеры, даркнет, санкции, ransomware), авто-флаг и очередь ревью. 70+ категорий сущностей; депозит с high-risk кошелька → немедленный алерт и заморозка зачисления.

Сущности данных (модель)

• Wallet (id, chain, type hot/warm/cold, custody MPC/HSM/single, office_id, xpub).
• Address (address, wallet_id, derivation_path, office_id, deal_id?, is_change).
• OnChainTx (txid, chain, from, to, asset, amount, block, confirmations, status, energy/fee, memo, risk_score).
• ReconMatch (onchain_tx_id, deal_id, score, status matched/unmatched/manual).
• Balance snapshot (wallet_id, asset, amount, as_of_block).
• SweepJob / GasTopUp (источник, назначение, сумма, fee).

Лучшие практики и риски

• Не хранить hot больше дневной потребности; cold — основной резерв; sweep по порогу.
• Watch-only через xpub для индексации — приватные ключи не в учётной системе.
• Policy engine (Fireblocks/BitGo): роли, пороги сумм, обязательные апруверы, co-signer — ни одна выплата без нужных подтверждений.
• Идемпотентный upsert транзакций по txid (исключить двойной учёт при ретраях/реоргах).
• Proof-of-reserves: периодическая сверка суммы балансов кошельков с обязательствами учёта.
• Типичные ошибки: чтение неподтверждённых блоков, игнор fake-deposit/zero-value tx, отсутствие буфера газа, незахеджированный hot-кошелёк без лимитов, доверие к адресу из истории (poisoning), один seed на весь бизнес без офисной сегрегации.

Регуляции/стандарты

BIP32/39/44 (деривация), FIPS 140-2/3 (HSM), SOC 2 Type II (инфра-провайдеры), FATF Travel Rule (передача данных отправителя/получателя при выводах между VASP), AML/KYC-скрининг адресов. Для TR-канала — учитывать локальный режим VASP; для UA-ФОП — фиат-комплаенс отдельно от on-chain.

Ключевые функции: - HD-генерация депозитных адресов (BIP32/44) с сегрегацией по офису через account'/address_index - Watch-only индексация по xpub без хранения приватных ключей в учётной системе - Hot/Warm/Cold многоуровневое хранение с динамическим распределением активов - MPC-подписание с распределением key-shares (Fireblocks/BitGo/Cobo) - HSM cold-storage (FIPS 140) для институционального резерва - Policy engine: роли, пороги сумм, обязательные апруверы, co-signer, whitelist адресов - On-chain мониторинг входящих через polling getblockbynum + фильтр по контракту/сигнатуре - Различение /wallet vs /walletsolidity (неподтверждённые vs финализированные) - Ожидание N подтверждений и переоткрытие сделки при reorg - Детекция ERC-20 Transfer-событий с защитой от fake-deposit (проверка реального изменения баланса) - Оценка газа (estimateenergy) и буфер fee_limit, аренда Energy на TRON - Gas-station дотирование TRX/ETH на свежие депозитные адреса перед sweep - Sweep остатков офисов в центральный treasury-кошелёк по порогу/расписанию - Авто-сверка on-chain↔сделки (1:1, 1:many, many:many) со скорингом и очередью расхождений - Crypto subledger с постингом агрегатов в главную книгу - Защита от address poisoning: фильтрация dust, скрытие unverified-токенов, валидация memo - Скрининг адресов на санкции/миксеры/даркнет (Chainalysis/TRM/Elliptic) с авто-флагом - Агрегация балансов по чейнам/офисам и proof-of-reserves сверка - Идемпотентный upsert транзакций по txid против двойного учёта - Поддержка Travel Rule при выводах между VASP

Источники: - https://blockeden.xyz/blog/2026/02/27/mpc-hsm-custody-architecture/ - https://www.liminalcustody.com/blog/hsm-vs-hardware-wallets-why-institutions-upgrade-to-hsm-cold-storage-in-2026/ - https://cordialsystems.com/post/securing-digital-asset-custody-the-role-of-mpc-in-hot-and-cold-wallets - https://www.trmlabs.com/resources/blog/understanding-address-poisoning-on-the-tron-blockchain - https://plasbit.com/research/address-poisoning-attack - https://chainstack.com/tron-rpc-usdt-trc20-infrastructure/ - https://developers.tron.network/docs/get-trc20-transaction-history - https://medium.com/@taojunlan5/how-to-listen-for-usdt-trc20-payments-in-node-js-without-running-a-full-node-67149ea6ac1d - https://learnmeabitcoin.com/technical/keys/hd-wallets/derivation-paths/ - https://www.cube.exchange/what-is/key-derivation-bip323944 - https://tres.finance/top-5-crypto-transaction-reconciliation-tools-for-enterprises/ - https://blog.cryptio.co/exchanges-and-custodians-reconcile-crypto-settlements-with-an-internal-ledger-system-at-scale - https://www.bitgo.com/resources/blog/crypto-treasury-management-guide/ - https://www.fireblocks.com/crypto-treasury-management-101 - https://www.chainup.com/blog/blockchain-analytics-explained/ - https://cryptotracelabs.com/blog/chainalysis-vs-elliptic-vs-trm-labs-which-platform-should-investigators-choose/ - https://developers.fireblocks.com/docs/capabilities - https://github.com/adrenaline0206/exchange-deposit-contract-explanation - https://arxiv.org/pdf/2006.06419 - https://docs.metamask.io/services/tutorials/ethereum/track-erc-20-token-transfers/

Ценообразование, курсы, спред-движок

Кратко: Раздел покрывает движок ценообразования back-office крипто/финтех: источники курсов (VWAP-агрегаторы, оракулы, биржевой стакан), формирование клиентского курса из базового через спред и наценку по тирам/объёму/валюте/каналу, динамическое ценообразование с inventory-skew, RFQ и фиксацию курса, контроль маржи и кросс-курсы фиат-пар. Показано, как это реализуют мелкий обменник, сеть филиалов и институциональный OTC-деск, с конкретными цифрами спредов (0.1-1%), механиками last-look и типичными рисками (stale rate, отрицательная маржа, арбитраж клиентом).

Ценообразование, курсы, спред-движок

Спред-движок — ядро монетизации любого обменника/OTC-деска: именно здесь рыночный «базовый» курс превращается в «клиентский», на разнице которых формируется валовая маржа. Модуль отвечает за приём котировок из внешних источников, расчёт базовой стоимости актива, наложение спреда и наценок по правилам, выдачу котировки клиенту (через калькулятор сайта, RFQ или прайс-лист менеджера), фиксацию курса на время сделки и контроль реализованной маржи post-trade.

Что делает модуль

1. Получение и нормализация курсов из множества источников, выбор «достоверного» mid-price.
2. Расчёт базового курса (cost basis) — сколько актив реально стоит для бизнеса прямо сейчас, включая стоимость хеджа/пополнения резерва.
3. Применение спреда и наценок по конфигурируемым правилам (тир клиента, объём, валюта, канал, направление, отделение).
4. Котирование: непрерывный стрим, индикативная котировка в калькуляторе или firm-quote по RFQ.
5. Фиксация курса (rate lock) на TTL сделки с обработкой истечения.
6. Контроль маржи: целевая vs реализованная, алерты на отрицательный спред, защита от арбитража.

Источники курсов

• Биржевые стаканы (order book / L2): top-of-book bid/ask с Binance, OKX, Bybit, Kraken — самый «свежий», но и самый шумный источник. Для расчёта реальной цены исполнения объёма берут не верх стакана, а средневзвешенную по глубине (depth-weighted price), чтобы учесть проскальзывание.
• Агрегаторы-индексы (VWAP): Kaiko, CryptoCompare, CoinGecko, Amberdata, BraveNewCoin собирают сделки со множества бирж, взвешивают по реальному объёму, отсеивают выбросы и фейковый объём и выдают единый global-market price. Chainlink Price Feeds строятся именно на этих VWAP-источниках в три слоя агрегации (data providers → node operators → oracle networks), обновляются по deviation threshold (например, при движении >0.3%) и по heartbeat (например, раз в час).
• Оракулы (on-chain): Chainlink (VWAP, не TWAP), Pyth, RedStone. TWAP-оракулы (Uniswap) сглаживают цену по времени — устойчивы к манипуляции, но лагают на волатильности, поэтому для котирования живых сделок не годятся, только для DeFi-залогов.
• Для фиата: ЕЦБ/ЦБ reference rates, провайдеры типа Open Exchange Rates / xe / Currencylayer; для крипто-фиат пар (USDT/TRY, USDT/UAH) — P2P-рынки и локальные обменники, где «справедливый» курс отличается от официального ЦБ.

Best practice — медиана из 3+ независимых источников с отбрасыванием выбросов, staleness-таймаутом (курс старше N секунд считается негодным) и circuit breaker при расхождении источников >X%.

Базовый курс vs клиентский курс

Базовый (mid / cost) — это внутренняя оценка стоимости. Клиентский получается наложением спреда: - client_buy = mid × (1 + spread_buy + markup) — курс, по которому клиент покупает крипту у нас (дороже). - client_sell = mid × (1 − spread_sell − markup) — по которому продаёт нам (дешевле).

Разница bid/ask и есть валовый спред — основной доход. По данным OTC-индустрии типичный спред 0.1–1% в зависимости от ликвидности актива, объёма, волатильности и истории отношений с клиентом. Принципиальный момент: базовый курс — это не голый рыночный mid, а reservation price (термин из модели Avellaneda-Stoikov): внутренняя оценка, скошенная под текущие резервы.

Спред и наценка по тирам / объёму / валюте

Конфигурация наценок — матрица правил: - По тиру клиента: VIP/постоянный получает уже спред, новый/розница — шире. Kraken: 0.20% до $500k, падает до 0.05% при обороте >$10M/мес. - По объёму: большой тикет → меньше % спреда (экономия на масштабе), но крупные блоки могут наоборот получать wider спред из-за рыночного импакта при хедже. - По валюте/паре: ликвидные (USDT/USD) — узкий спред; экзотика (USDT/TRY, USDT/UAH) — широкий, плюс отдельная fiat-наценка за стоимость кэша и страновой риск. - По каналу/отделению: наличные в офисе (Анталья/Аланья) дороже онлайна — учитывают стоимость инкассации, аренды, риск кассы; партнёрский OTC получает спред под его комиссию. - По направлению: асимметрия buy/sell для управления резервами (см. ниже).

Динамическое ценообразование (inventory skew)

Зрелые движки скашивают курс под текущие резервы, а не держат статичный спред. Модель Avellaneda-Stoikov: при нулевой позиции reservation price = mid; когда резерв USDT избыточен (long) — оба курса сдвигают вниз, чтобы стимулировать продажу клиентам; при дефиците (short) — вверх. Рост волатильности → агрессивнее скос и шире спред (удвоение волатильности учетверяет влияние на скос и рисковую компоненту спреда). Практические триггеры динамики: уровень резервов vs target по каждой валюте/офису, волатильность за окно, время до закрытия смены, стоимость пополнения/хеджа. Для сети филиалов это критично — резерв TRY в Анталье и USDT на онлайн-кошельке управляются независимо, и курс в каждом канале должен реагировать на свой инвентарь.

RFQ и индикативные котировки

Два режима выдачи цены: - Индикативная (non-binding) — число в калькуляторе на сайте / market color от менеджера; не обязывает к исполнению. - Firm quote (RFQ) — клиент запрашивает котировку на конкретный объём, движок возвращает твёрдую цену с TTL. Статусы котировки: indicative → firm pending verification → matched → expired/cancelled/settled. В крипто-OTC firm-quote живёт секунды (волатильные активы — короче), клиент подтверждает в окне ~5 сек. Это защищает деск от того, что клиент «снимет» устаревшую выгодную цену. RFQ позволяет исполнять крупные блоки без проскальзывания публичного стакана и без засветки до сеттлмента.

Фиксация курса (rate lock)

При подтверждении сделки курс фиксируется на TTL: движок ведёт countdown-таймер, показывает клиенту, блокирует исполнение по истёкшей котировке. Механика last look (из FX): провайдер берёт короткое окно (hold time / order review time) на price-check перед финальной фиксацией. Ключевая этика (GFXC FX Global Code): проверка должна быть симметричной — отклонять отклонение цены за толеранс в любую сторону, а не только когда движение против деска (асимметричный last-look — токсичная практика, бьёт по клиенту). Для офисного нала фиксация = момент создания заявки/расписки; рассинхрон между фиксацией и реальным приёмом нала — источник убытка на волатильности.

Маржа и её контроль

• Целевая маржа закладывается в спред; реализованная считается post-trade: (client_rate − fill_cost) × volume, где fill_cost — реальная цена хеджа/пополнения, а не котировочный mid.
• Алерты на отрицательный спред (когда наценка не покрыла движение рынка между котировкой и исполнением), на маржу ниже порога, на расхождение источников.
• TCA (transaction cost analysis): fill-rate по провайдерам, slippage-симметрия, паттерны реджектов — для оценки качества исполнения хеджа.
• Сверка on-chain факта с зафиксированным курсом для крипто-плеча.

Кросс-курсы фиат-пар

Для пар без прямой ликвидности курс собирают триангуляцией через USD/USDT: A/B = (A/USD) × (USD/B). Пример: EUR/TRY = (EUR/USD) × (USD/TRY). При триангуляции спреды складываются — кросс по bid/ask шире суммы прямых, поэтому на каждом «ноге» закладывают свой спред. Учёт в USDT упрощает: USDT — базовая валюта-якорь, все операционные валюты (USD>EUR>TRY>UAH>RUB) котируются к ней, а кросс между ними считается через USDT-ноги. Риск — триангуляционный арбитраж: если кросс-курс рассинхронен с прямыми котировками, клиент может «прокрутить» цепочку; движок должен пересчитывать кросс из единого mid, а не хранить независимые числа.

Как реализуют разные операторы

• Мелкий обменник: один источник курса (Binance + ручной коэффициент), статичный спред в %, курс из Google-таблицы/админки; маржа считается вручную постфактум. Просто, но уязвимо к stale-rate и арбитражу.
• Сеть филиалов: централизованный rate-движок, наценки по матрице (офис × валюта × тир), inventory-skew по резервам каждого офиса, фиксация курса в момент заявки, дашборд реализованной маржи. Нал и онлайн котируются отдельно.
• Институциональный OTC-деск: агрегация ликвидности от tier-1 LP (B2C2, Cumberland, Wintermute, Jane Street), proprietary/AI pricing-engine, RFQ со стримом и last-look, принципиальная (warehouse + hedge) либо агентская (явный markup/commission) модель, авто-хедж позиции.

Лучшие практики и типичные ошибки

• Делать: медиана из нескольких источников + staleness-таймаут + circuit breaker; reservation price с inventory-skew; короткий TTL котировки; симметричный last-look; post-trade сверка реализованной маржи; единый mid для всех кросс-курсов.
• Ошибки: котирование по голому top-of-book без учёта глубины; статичный спред без реакции на резервы/волатильность; устаревший курс (stale) → клиент снимает арбитраж; асимметричный last-look (репутационный и регуляторный риск по FX Global Code); хранение кросс-курсов независимо от прямых пар; смешивание котировочного mid и реальной стоимости хеджа при расчёте маржи (иллюзия прибыли).

Ключевые функции: - Агрегация курсов из нескольких источников (биржевые стаканы, VWAP-индексы, оракулы) с выбором достоверного mid - Depth-weighted расчёт цены исполнения объёма (учёт проскальзывания по глубине стакана) - Staleness-контроль и circuit breaker при расхождении источников выше порога - Расчёт базового курса (cost basis) с учётом стоимости хеджа/пополнения резерва - Reservation price с inventory-skew: скос курса под текущие резервы (Avellaneda-Stoikov) - Матрица наценок: тир клиента × объём × валюта × канал × отделение × направление - Объёмные тиры спреда (меньше % на больший тикет, либо wider на крупный блок из-за импакта) - Отдельная фиат-наценка за стоимость нала и страновой риск (TRY/UAH) - Динамическое расширение спреда при росте волатильности - Выдача индикативной (non-binding) котировки в калькуляторе/прайс-листе - RFQ-движок: firm-quote на объём с TTL и статусной моделью (indicative→firm→matched→settled/expired) - Rate lock с countdown-таймером и блокировкой исполнения по истёкшей котировке - Симметричный last-look / price-check перед финальной фиксацией - Триангуляция кросс-курсов фиат-пар через USD/USDT с суммированием спредов по ногам - Защита от триангуляционного арбитража (единый mid для всех кросс-пар) - Расчёт целевой vs реализованной маржи post-trade (client_rate − fill_cost) - Алерты на отрицательный спред и маржу ниже порога - TCA: fill-rate по провайдерам, slippage-симметрия, паттерны реджектов - Авто-хедж позиции и поддержание target-резервов по валютам/офисам - Сверка зафиксированного курса с on-chain фактом исполнения

Источники: - https://www.liquidmercury.com/resources/crypto-otc-desk-software - https://www.bitget.com/academy/crypto-otc-desks - https://www.dextools.io/tutorials/what-is-otc-trading-in-crypto-guide-2026 - https://finchtrade.com/blog/understanding-request-for-quote-trading-how-it-works-and-why-it-matters - https://www.cube.exchange/what-is/rfq-request-for-quote - https://www.osl.com/en/bits/article/how-to-execute-large-crypto-trades-using-rfq - https://docs.chain.link/data-feeds/price-feeds - https://chain.link/education-hub/twap-vs-vwap - https://smartcontentpublication.medium.com/twap-oracles-vs-chainlink-price-feeds-a-comparative-analysis-8155a3483cbd - https://hummingbot.org/blog/guide-to-the-avellaneda--stoikov-strategy/ - https://uditsamani.com/avellaneda-stoikov/ - https://www.globalfxc.org/uploads/gfxc_report_last_look-1.pdf - https://databento.com/microstructure/last-look - https://finerymarkets.com/blog/last-look-execution-in-crypto - https://www.okumarkets.com/blog/triangulation/ - https://insightsoftware.com/blog/how-to-get-fx-cross-rates-triangulation-vs-direct-from-source/ - https://corporatefinanceinstitute.com/resources/foreign-exchange/cross-rates/ - https://finerymarkets.com/blog/how-to-launch-a-crypto-otc-desk

Комплаенс, AML/CFT, Travel Rule, мониторинг транзакций

Кратко: Раздел детально описывает комплаенс/AML-CFT модуль крипто back-office: санкционный и PEP-скрининг, мониторинг транзакций с правилами и алертами, риск-рейтинг клиентов, SAR/STR-отчётность, Travel Rule (FATF R.16, IVMS101, пороги по юрисдикциям), chain-analytics (Chainalysis/Elliptic/TRM/Crystal), хранение доказательной базы и лицензирование VASP/MSB/CASP. Показано, как это реализуют мелкий обменник, сеть филиалов и институциональный OTC-деск, плюс лучшие практики и типичные ошибки. Цифры и вендоры подтверждены источниками (FATF, FinCEN, MiCA, Notabene и др.).

Комплаенс, AML/CFT, Travel Rule, мониторинг транзакций

Комплаенс-модуль — это «нервная система» легального крипто-обменника: он связывает онбординг клиента, ончейн-данные, кассовые операции и регуляторную отчётность в единый риск-контур. Для бизнеса с наличными офисами (Турция), онлайн-OTC через партнёрскую сеть и фиатным ФОП-каналом (Украина) этот модуль решает три задачи одновременно: не пропустить грязные деньги в кассу, не отправить средства санкционному адресу и доказать регулятору/банку-партнёру, что «должная осмотрительность» (due diligence) выполнялась и доказуема при каждой транзакции, а не раз в квартал.

Что делает модуль

Модуль покрывает полный жизненный цикл финансового мониторинга по риск-ориентированному подходу (RBA) FATF: (1) скрининг клиента и контрагента при онбординге и на постоянной основе; (2) присвоение и пересмотр риск-рейтинга; (3) реал-тайм и пост-фактум мониторинг транзакций по набору правил; (4) триаж алертов и кейс-менеджмент; (5) формирование и подача SAR/STR; (6) исполнение Travel Rule на исходящих/входящих переводах; (7) хранение доказательной базы и аудит-трейла. Современный стандарт — режим «always-on»: проверка при каждой операции, а санкционные списки обновляются ежедневно.

Ключевые функции (детально)

• Санкционный и PEP-скрининг. Имена клиентов проверяются против OFAC SDN, EU/UK Consolidated, UN SC, локальных списков (для региона — украинские/НБУ-листы); адреса кошельков — против санкционных адресов (OFAC SDN-крипто, Tornado Cash и т.п.). Скрининг включает PEP, RCA (родственники/приближённые), adverse media. Критично: fuzzy-matching с настройкой порога (транслитерация кириллицы → латиницы даёт ложные срабатывания), дедупликация, дельта-rescreening при обновлении списка.
• Мониторинг транзакций (TM). Правила на off-chain (сумма, частота, канал) и on-chain сигналах. Классические типологии-триггеры: structuring/smurfing (дробление под порог), rapid in-out (получил крипту — мгновенно вывел в фиат), layering через множество кошельков, chain-hopping, взаимодействие с миксерами/privacy-coins, экспозиция к darknet/scam/ransomware-кластерам, velocity-аномалии относительно профиля клиента.
• KYT / wallet screening. Через chain-analytics определяется риск-скор адреса по прямой атрибуции (адрес сам в списке) и косвенной (история контрагентов, расстояние «хопов» до рискового кластера). Это основной инструмент для self-hosted (unhosted) кошельков, где нет встречного VASP.
• Риск-рейтинг клиента (CRR). Взвешенная модель: география (30%), тип клиента/деятельность, PEP-статус, источник средств/благосостояния (SoF/SoW), поведение транзакций, канал доставки (наличные/онлайн/партнёр), продукт. Результат — Low/Medium/High → определяет глубину CDD/EDD и частоту пересмотра.
• Travel Rule. Сбор и передача данных отправителя и получателя (originator/beneficiary) между VASP по стандарту IVMS101 через протоколы (TRP, TRISA, TRUST, OpenVASP) или агрегаторы (Notabene Gateway). Включает counterparty VASP attribution, проверку self-hosted-кошелька на принадлежность клиенту.
• SAR/STR-воркфлоу. Эскалация алерта → расследование → решение MLRO → подача в FIU. В США: SAR в FinCEN через BSA E-Filing в течение 30 дней (до 60). В ЕС — STR. Действует «tipping-off ban»: клиента нельзя информировать.
• Кейс-менеджмент и аудит. Очередь алертов, SLA, диспозиция (false positive / escalate), привязка доказательств (скриншоты графа, KYC-документы, чек кассы), неизменяемый журнал.
• Хранение доказательной базы. Минимум 5 лет (BSA/FATF) хранения KYC, записей операций, SAR и supporting evidence; ончейн-снапшоты сохраняются, т.к. атрибуция адреса со временем меняется.
• Лицензирование как часть комплаенса. Модуль фиксирует обязательства лицензии: регистрация MSB в FinCEN + state money transmitter (США), авторизация CASP по MiCA (ЕС, Art. 59 — 10 услуг), регистрация VASP. Турция в 2024–2025 ввела лицензирование крипто-провайдеров под надзором CMB; украинский фиат-канал работает в режиме ФОП/банковского комплаенса до полноценного регулирования.

Сущности данных (модель)

Customer (риск-профиль, KYC-уровень) · WalletAddress (риск-скор, источник, владелец) · ScreeningHit (список, score, диспозиция) · Transaction (on/off-chain, TM-флаги) · Alert (правило, severity, статус) · Case (расследование, MLRO-решение) · SAR/STR (статус подачи, референс FIU) · TravelRuleMessage (IVMS101 payload, counterparty VASP) · AuditLog. Ключевое связующее звено — линковка ончейн-адреса с off-chain Customer.

Рабочие процессы

1. Онбординг: KYC → санкции/PEP/adverse-media → CRR → решение accept/reject/EDD.
2. Pre-transaction (исходящий вывод): KYT-скрин адреса получателя → Travel Rule (если контрагент-VASP) → блок при санкционном/высокорисковом адресе.
3. Ongoing TM: правила гоняют операции → алерт → триаж → кейс → (опц.) SAR/STR.
4. Periodic review: перескрининг при обновлении списков, пересмотр CRR.

Как реализуют разные операторы

• Мелкий обменник / сеть наличных офисов. Часто комбинируют ручной KYC + бюджетный KYT (AMLBot, Crystal, Bitrace, GetBlock-подобные) с порогами на дроблении наличных и обязательным скрином адреса вывода. Главная боль — кэш-структурирование между офисами и партнёрами; нужен агрегированный мониторинг по клиенту, а не по отдельной кассе. Travel Rule часто не применяется напрямую (P2P/self-hosted), но санкционный скрин адреса обязателен.
• Сеть филиалов / партнёрская OTC-модель. Централизованный комплаенс-движок поверх распределённых касс: единый CRR клиента, агрегация операций по всем точкам/партнёрам, KYC партнёров как «sub-VASP», лимиты и эскалация в head-office MLRO. Риск: партнёр становится «слепой зоной» — нужен контроль источника крипты, поступающей от партнёра.
• Институциональный OTC-деск. Двойной стек chain-analytics (например Chainalysis как investigations + Elliptic/TRM как screening-overlay), полноценный Travel Rule через Notabene/TRP с counterparty due diligence и VASP-директорией, формализованный SAR-процесс, выделенный MLRO, регулярный независимый аудит AML-программы.

Лучшие практики

• Риск-ориентированный подход с документированным обоснованием порогов и весов.
• Тюнинг правил под реальные типологии, регулярный back-testing на ложные срабатывания (high false-positive — главная операционная боль TM).
• Два независимых chain-analytics-источника для крупных операторов (атрибуция расходится между вендорами).
• Ежедневное обновление санкционных списков и дельта-rescreening.
• Чёткое разделение ролей: аналитик → MLRO → подача; tipping-off ban строго соблюдается.
• Сохранение ончейн-снапшота на момент решения (атрибуция меняется).

Типичные ошибки и риски

• Адрес ≠ личность: ончейн псевдонимность ломает наивный скрининг — нужна косвенная атрибуция.
• Кириллица/транслитерация → массовые false positive в санкционном матчинге.
• Мониторинг по кассе, а не по клиенту → пропуск structuring между офисами/партнёрами.
• Игнор «Sunrise Issue»: контрагент-VASP в другой юрисдикции ещё не обязан соблюдать Travel Rule — нужен fallback (behaviour-led risk assessment).
• Просроченная подача SAR/STR (30 дней) и непрерывность аудит-трейла.
• Недооценённый self-hosted-канал: EDD и proof-of-ownership обязательны в ЕС/UK/CH/SG.

Релевантные продукты/стандарты

Chain-analytics/KYT: Chainalysis (KYT, доказательность для суда, 1500+ клиентов), Elliptic (Lens, кросс-чейн), TRM Labs (скорость/автоматизация), Crystal Intelligence (популярен в RU/CIS-сегменте), Nominis (для VASP). Travel Rule: Notabene, Sumsub Travel Rule, 21 Analytics, протоколы TRP/TRISA/TRUST/OpenVASP, стандарт IVMS101. Санкции/скрининг: FinScan, sanctions.io, ComplyAdvantage. Стандарты/регуляции: FATF R.15/R.16 (Travel Rule), FinCEN BSA (порог Travel Rule $3,000), EU TFR/MiCA (порог €0 для CASP↔CASP), MAS (SGD 1,500), рекомендуемый FATF-порог USD/EUR 1,000.

Ключевые функции: - Санкционный скрининг имён и адресов (OFAC SDN, EU/UK/UN, локальные списки) с fuzzy-matching и дельта-rescreening - PEP/RCA и adverse-media скрининг при онбординге и периодически - KYT / wallet screening: риск-скор адреса по прямой и косвенной (хоп-дистанция) атрибуции - Мониторинг транзакций по правилам: structuring, rapid in-out, layering, chain-hopping, миксеры/privacy-coins - Velocity/аномалийный мониторинг относительно поведенческого профиля клиента - Риск-рейтинг клиента (CRR): взвешенная модель география/продукт/канал/PEP/SoF-SoW - Экспозиционный анализ к рисковым кластерам (darknet, ransomware, scam, sanctioned services) - Travel Rule: формирование/передача IVMS101 payload между VASP (TRP/TRISA/TRUST/Notabene Gateway) - Counterparty VASP attribution и идентификация self-hosted (unhosted) кошельков - EDD и proof-of-ownership для операций с self-hosted кошельками - Триаж алертов и кейс-менеджмент с SLA и диспозицией (false positive/escalate) - Воркфлоу SAR/STR: эскалация → расследование → решение MLRO → подача в FIU (FinCEN 30 дней) - Соблюдение tipping-off ban (запрет информирования клиента) - Хранение доказательной базы и аудит-трейла минимум 5 лет + ончейн-снапшоты - Перескрининг и пересмотр риск-профиля при обновлении санкционных списков - Контроль лицензионных обязательств: MSB/FinCEN, MiCA CASP, VASP-регистрация, CMB (Турция) - Агрегация операций по клиенту across офисов/партнёров для выявления structuring - Блокировка/hold транзакции при санкционном или высокорисковом адресе получателя - Back-testing и тюнинг правил для снижения false-positive rate - Двойной стек chain-analytics (investigations + screening overlay) для крупных операторов

Источники: - https://www.fatf-gafi.org/content/dam/fatf-gafi/recommendations/Best-Practices-Travel-Rule-Supervision.pdf - https://sumsub.com/blog/what-is-the-fatf-travel-rule/ - https://hacken.io/discover/crypto-travel-rule/ - https://www.elliptic.co/blockchain-basics/what-is-the-travel-rule - https://blog.amlbot.com/crypto-kyc-requirements-in-2025-regulatory-standards-for-vasps/ - https://amlwatcher.com/blog/crypto-travel-rule-vasp-compliance/ - https://www.chainalysis.com/glossary/transaction-monitoring/ - https://sumsub.com/blog/transaction-monitoring/ - https://www.trmlabs.com/guides/crypto-compliance-program-guide-for-financial-institutions - https://seon.io/resources/cryptocurrency-transaction-monitoring/ - https://cryptotracelabs.com/blog/chainalysis-vs-elliptic-vs-trm-labs/ - https://finconduit.com/resources/blockchain-analytics-providers-compared - https://www.nominis.io/insights/nominis-the-trm-labs-elliptic-and-chainalysis-alternative-made-for-vasps - https://blog.amlbot.com/sanctions-screening-for-crypto-businesses/ - https://www.sanctions.io/blog/sanctions-screening-for-crypto-vasps - https://www.trmlabs.com/glossary/sanctions-screening - https://www.finscan.com/post/finscan-launches-digital-wallet-stablecoin-payments-screening-for-global-aml-sanctions-compliance - https://www.elliptic.co/blockchain-basics/what-are-ofac-crypto-sanctions - https://www.fincen.gov/resources/frequently-asked-questions-regarding-fincen-suspicious-activity-report-sar - https://www.innreg.com/blog/suspicious-activity-reports-guide - https://www.wilmerhale.com/en/insights/client-alerts/20251028-fincen-clarifies-suspicious-activity-reporting-requirements - https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica - https://www.fintecharbor.com/msb-vs-vasp-licenses-comparison/ - https://coincub.com/blog/vasp-types/ - https://amlyze.com/customer-risk-aml/ - https://www.azakaw.com/blog/customer-risk-rating - https://sumsub.com/blog/aml-and-fraud-risk-assessment/ - https://notabene.id/travel-rule-messaging-protocols/ivms-101 - https://www.21analytics.co/glossary/inter-vasp-messaging-standard-ivms/ - https://www.chainalysis.com/blog/travel-rule-compliance-unhosted-wallets/ - https://notabene.id/post/how-can-vasps-ensure-travel-rule-compliance-during-transactions-with-unhosted-wallets - https://blog.amlbot.com/counterparty-vasp-due-diligence-guide/ - https://vc.ru/crypto/2334128-tsifrovoy-komplaens-2025-kak-biznesu-proyti-aml-proverku-uspeno - https://blog.profvest.com/2025/11/reiting-aml-servisov-dlya-proverki-kriptovalyut.html

OTC-специфика: RFQ, блок-трейды, расчёты, ликвидность

Кратко: OTC desks execute large, off-book block trades via negotiated RFQ at a single firm price, sidestepping the slippage retail order books inflict. The module's core is an RFQ/quote engine with firm short-lived prices, plus settlement (DvP/atomic, escrow, netting), counterparty credit limits, and liquidity aggregation across exchanges, market makers and other desks. Implementation ranges from chat/Telegram-driven manual desks at small shops to FIX/REST multi-dealer RFQ platforms with custodian integration and travel-rule compliance at institutional scale.

OTC-специфика: RFQ, блок-трейды, расчёты, ликвидность

Что делает модуль

OTC-деск (over-the-counter) — это слой исполнения крупных сделок вне публичного стакана, напрямую между двумя контрагентами. Принципиальное отличие от retail-обменника или биржи: вместо того чтобы «съедать» уровни order book (где покупка $10M BTC реально сдвигает цену на 200–500 б.п. и стоит $200–500k проскальзывания), деск котирует одну твёрдую цену на весь объём. Клиент видит не множество лимиток, а единый quote, который либо принимает, либо нет. Модуль управляет полным жизненным циклом: запрос котировки → переговоры/quote → исполнение → тикет → расчёт (settlement) → подтверждение и хеджирование. Поверх — управление ликвидностью, кредитными лимитами контрагентов и комплаенсом.

Для бизнеса с онлайн-OTC через партнёров это и есть основной «институциональный» канал: крупные клиенты не идут в кассу, а запрашивают курс на $50k–$1M в чат, получают фиксированный курс и расчёт в USDT.

RFQ — Request For Quote (ядро десковой логики)

RFQ — фундаментальный протокол ценообразования, пришедший из традиционного OTC/FX. Поток:

1. Запрос (RFQ): клиент указывает актив, направление (buy/sell или request two-way — двусторонняя цена, чтобы не раскрывать намерение) и size. Каналы: голос, чат (Telegram/Signal), проприетарный GUI, или FIX/REST API у крупных десков.
2. Котировка: деск смотрит глубину рынка, своё инвентарь-позиционирование и риск, отвечает в течение секунд. Quote бывает one-way (только bid или ask) или two-way. Институциональная котировка — firm/executable (обязывающее предложение), не индикативная.
3. Окно жизни (validity / TTL): firm-цена держится обычно 5–30 секунд, затем деск её рефрешит. Это критично: при волатильности цена «убегает» — если рынок идёт против десков, ваш выгодный quote истечёт; если в пользу десков — вы исполните по уже устаревшей цене.
4. Принятие (accept / lift): клиент «лифтует» котировку. Часто практикуют multi-dealer RFQ — фонд пингует 4 десков сразу и берёт самую узкую цену.
5. Last look: провайдер может за миллисекунды отклонить акцепт, если цена сильно ушла — спорная, но распространённая в FX/крипто практика; десковый софт должен это логировать (reject rate — KPI здоровья ликвидности).

В FIX это моделируется сообщениями QuoteRequest (R), Quote (S), QuoteCancel, QuoteStatusReport, QuoteRequestReject, плюс RFS (Request For Stream) для потоковых котировок «весь день». Минимальный набор полей тикета: RFQ-ID, asset/pair, side, quantity, quoted price, spread, validity timestamp, counterparty-ID, settlement instruction (сеть, адрес, тайминг, неттинг).

Блок-трейды и хеджирование

Block trade — крупная сделка, согласованная приватно, чтобы не «утекла» в рынок до исполнения (information leakage). Типичный институциональный workflow: RFQ к 4 дескам → lift самой узкой → settle T+0 через кастодиана. Чтобы закрыть риск между исполнением и расчётом, десков хеджирует: например, шортит эквивалент в perpetual futures на регулируемой бирже, затем раскручивает шорт по мере оседания OTC-сделки. Маркет-мейкерский десков может держать inventory и закрывать клиента «с книги», агентский — сразу перекрывает на бирже/у другого LP (back-to-back).

Settlement: DvP, эскроу, неттинг

Расчёт — самое рисковое место OTC, потому что момент исполнения и момент поставки разнесены (Herstatt / principal risk): одна сторона платит/поставляет первой и рискует, что вторая исчезнет/обанкротится.

• DvP (Delivery versus Payment): поставка актива происходит тогда и только тогда, когда происходит платёж. On-chain реализуется смарт-контрактом-эскроу: обе стороны вносят свои ноги в контракт, атомарно происходит обмен, при провале любой ноги — полный revert и возврат активов. Это atomic settlement, убирающий counterparty risk. Cross-chain DvP решают через Chainlink CCIP и подобные.
• Эскроу: нейтральный агент (смарт-контракт или доверенный кастодиан/прайм-брокер) держит обе стороны до полного исполнения.
• Неттинг: при множестве сделок с одним контрагентом считают нетто-обязательство (как в FX-неттинге по отчётам Angell/Lamfalussy) — двигают только разницу, экономя on-chain комиссии и снижая расчётный риск. Multi-venue netting — частая фича институционального OTC.
• Тайминг: OTC настраивается — T+0 для немедленного, до T+1/T+3 для согласования с движением фиата. Большинство crypto-to-crypto сделок settle в USDT/USDC, потому что SWIFT медленный и дорогой; регулируемые стейблкоины сделали T+0 жизнеспособным в институциональном масштабе.

Софт должен автогенерировать settlement instructions сразу при исполнении: что поставить, куда (адрес/кастодиан), когда. Интеграция с кастодианами даёт straight-through processing от тикета до перевода.

Ликвидность, LP и кредит контрагента

• Liquidity aggregation: прайм-брокер/агрегатор сливает ликвидность с CEX, DEX и других OTC-десков в единый стакан, дробит ордер и маршрутизирует по лучшему спреду (smart order routing), снижая slippage.
• Кредитные лимиты: pre-trade проверки на лимит на контрагента, позиционный лимит, концентрационные правила встроены прямо в путь исполнения; real-time мониторинг ловит расширение спреда, latency-спайки, аномальный reject rate.
• Прайм-брокер: даёт клиенту одну кредитную линию на всю сеть LP, управляет коллатералом/маржой кросс-венью. Часто prime ценен именно тем, что договаривается о кредите с десками под клиентский коллатерал в кастоди — клиент получает лучшие линии, чем напрямую.

Как реализуют разные операторы

• Мелкий обменник / partner OTC: RFQ полностью в Telegram/Signal, цена считается вручную (биржевой mid + маржа), расчёт — перевод USDT по факту получения фиата, эскроу = доверие/репутация. Риск-контроль ручной, лимиты «в голове». Главная боль — нет аудита и реконсиляции (как раз то, что закрывает CRM/леджер).
• Сеть филиалов: полуавтоматический quote-движок, общий inventory-пул на офисы, лимиты на партнёра, неттинг внутрисетевых обязательств, единый USDT-учёт.
• Институциональный десков: FIX/REST multi-dealer RFQ, custodian-интеграция, DvP/atomic settlement, формальные credit lines, 24/7 voice/chat coverage, полное trade reporting. Вендоры: Talos, Liquid Mercury, Finery Markets, Integral, B2Broker; десков Kraken/Crypto.com/Binance OTC.

Лучшие практики и типичные ошибки

• Фиксировать settlement-путь в момент акцепта, а не «договариваться после» — иначе спор о сети/комиссиях/тайминге.
• Логировать каждую котировку (включая отклонённые last-look) для аудита best execution и анализа reject rate.
• Не давать клиенту истечь окну молча — явный countdown/expiry в UI.
• Сегрегировать риск: pre-trade лимиты, sanctions screening, проверка одобрения контрагента до котировки.
• Travel Rule (FATF/EU TFR): OTC-десков — covered entity; с дек.2024 в ЕС полные данные отправителя/получателя по каждому переводу без минимального порога; MiCA требует CASP-лицензию, CDD/EDD, transaction monitoring.
• Частые провалы: principal risk без DvP/эскроу; единый «жирный» контрагент без концентрационных лимитов; хедж не поставлен и десков ловит рыночный гэп; chat-only десков без структурированных тикетов теряет реконсиляцию (отрасль массово мигрирует с чата на платформы именно из-за фрагментации ликвидности и отчётности).

Ключевые функции: - RFQ-движок: приём запроса (актив/направление/size) по голосу, чату, GUI, FIX/REST - Генерация firm-котировок (one-way / two-way) с настраиваемым окном жизни 5–30 сек - Quote validity / TTL-таймер с авто-expiry и refresh при истечении - Multi-dealer RFQ: рассылка нескольким LP и lift самой узкой цены - Last-look: миллисекундное отклонение акцепта при движении цены + логирование reject rate - Блок-трейд исполнение единой ценой на весь объём (anti-slippage) - Авто-хеджирование позиции (perp-шорт / back-to-back перекрытие на бирже/LP) - DvP / atomic settlement через смарт-контракт-эскроу с revert при провале ноги - Эскроу-агент (смарт-контракт или кастодиан) до полного исполнения обеих ног - Неттинг обязательств по контрагенту и multi-venue netting - Авто-генерация settlement instructions (актив, адрес/кастодиан, сеть, тайминг) при исполнении - Настраиваемый тайминг расчёта T+0…T+3, расчёт в USDT/USDC - Liquidity aggregation: единый пул из CEX/DEX/других десков + smart order routing - Pre-trade кредитные/позиционные/концентрационные лимиты на контрагента в пути исполнения - Real-time мониторинг спреда, latency, reject rate и алертинг - Inventory / book management десков (маркет-мейкер vs агентская модель) - Тикет и trade confirmation с полями RFQ-ID, цена, спред, контрагент, settlement - FIX-сообщения QuoteRequest/Quote/QuoteCancel/QuoteStatusReport/RFQReject - Travel Rule / KYC / sanctions screening и trade reporting для комплаенса - Audit trail всех котировок (включая отклонённые) для best-execution и реконсиляции

Источники: - https://www.dextools.io/tutorials/what-is-otc-trading-in-crypto-guide-2026 - https://finchtrade.com/blog/understanding-request-for-quote-trading-how-it-works-and-why-it-matters - https://finchtrade.com/blog/otc-desk-vs-crypto-exchanges-key-differences-for-institutional-investors - https://www.liquidmercury.com/resources/crypto-otc-desk-software - https://www.liquidmercury.com/resources/crypto-prime-brokerage - https://finerymarkets.com/blog/how-to-launch-a-crypto-otc-desk - https://support.kraken.com/articles/360021967711-introducing-the-kraken-otc-desk - https://chain.link/article/cross-chain-delivery-vs-payment-dvp - https://chain.link/article/atomic-settlement-onchain-dvp - https://docs.bitbond.com/asset-tokenization-suite/token-tool/automate-payments/delivery-vs.-payment-dvp - https://blog.aplo.io/what-is-a-crypto-prime-broker-and-how-does-it-compare-to-market-makers-and-otc-desks/ - https://www.integral.com/products/digital/liquidity-aggregation/ - https://www.talos.com/our-solutions/rfq-platform - https://fiximate.fixtrading.org/legacy/en/FIX.5.0SP2/body_505482.html - https://www.onixs.biz/fix-dictionary/4.4/msgtype_r_82.html - https://github.com/joaquinbejar/otc-rfq - https://www.bis.org/cpmi/publ/d06.pdf - https://www.innreg.com/blog/mica-regulation-guide - https://blog.amlbot.com/eu-crypto-aml-platform-guide/ - https://blog.tokenmetrics.com/p/best-crypto-otc-desks-for-large-block-trades-2026

Сеть партнёров/агентов/филиалов, комиссии и выплаты

Кратко: Раздел по модулю сети партнёров/агентов/филиалов, комиссий и выплат для крипто/финтех back-office.

Сеть партнёров/агентов/филиалов, комиссии и выплаты

Модуль — операционно-финансовое ядро распределённой обменно-платёжной сети: кто и где исполнил операцию, сколько участник заработал или должен, сколько сеть заработала. Близок к MVTS (money or value transfer services по FATF) и hawala, где деньги физически не двигаются, а агенты-хаваладары в разных городах гасят позиции неттингом; крипто-вариант заменяет курьерский неттинг на USDT-леджер. Модель «выдаёт партнёр в городе клиента»: клиент сдаёт USDT деску, наличные выдаёт партнёр из своей кассы — возникает межфилиальная выдача (inter-branch delivery), сеть должна партнёру, неттинг долга отдельный процесс.

Ключевые функции

• Реестр контрагентов с ролевой моделью: филиал (полная консолидация P-and-L), франшиза (роялти/комиссия), агент-реферал (процент). FATF Rec.14/16 требует реестр агентов, due diligence (background check, financial audit, AML-capability), ответственность принципала; agent risk — отдельная ось риск-оценки.
• Спред-модель на точку: курс деска плюс наценка; OTC-практика — комиссия 0.1-0.5% или встроенный спред 0.1-1%, делится по сплиту сеть/партнёр.
• Inter-branch delivery: два плеча (приём актива деском, выдача наличных партнёром), встречное обязательство в валюте выдачи, переоценка в USDT, очередь на неттинг.
• Net-settlement: по hawala-логике фиксируются дельты, переводится нетто-остаток; циклы T+1/еженедельно, порог расчёта, направление досыла.
• Float/prefunding: оборотный остаток партнёра (nostro/vostro аналог), контроль достаточности.
• Affiliate-калькулятор: процент от оборота, многоуровневые схемы (до 50% плюс 10% второго уровня), окно атрибуции, post-commit accrual.
• Прогрессивная шкала бонусов управляющим: маржинальные тиры (повышенная ставка только на превышение) плюс accelerator-кикеры; калибровка 2-й тир 30-40%, верхний 10-15%, новичкам ramp 2-3 квартала.
• Statement и акт сверки нетто-позиции; consolidated P-and-L с per-branch разрезом и элиминацией intercompany; лимиты/алерты (float, незакрытая позиция, аномалии курса).

Модель данных

partner (own_branch/franchise/agent, AML-статус, валюта); branch_wallet (prefunded_float); deal (актив, сумма, курс, точка приёма/выдачи); inter_branch_delivery; commission_accrual; settlement_ledger_entry; payout; manager_bonus.

Как реализуют операторы

Мелкий обменник (1-2 точки): Excel/Sheets, спред в уме, фикс-комиссия, неттинг наличными; риск — нет акта сверки. Сеть/франшиза: per-branch P-and-L, intercompany-модуль (трансферы, роялти, management fee), location-level visibility, float-лимиты. Институциональный OTC-деск: agency vs principal, тиры (Kraken 0.2% до 500k USD, 0.05% свыше 10M/мес), white-label, settlement T+0/T+1, nostro/vostro prefunding, agent-oversight FATF.

Практики и риски

Практики: post-commit accrual; single source of truth в USDT с фиксацией курса; регулярный акт сверки; маржинальные тиры, не обрыв; agent DD как gate; лимит позиции = кредитный лимит. Риски: курсовой риск незакрытой позиции (TRY/UAH к USDT); float-разрыв; AML-ответственность за агента; double-counting в консолидации; бонусный cliff; «честное слово» вместо леджера.

Стандарты

FATF Rec.14 (регистрация MVTS), Rec.16 (travel rule плюс agent oversight); FATF Virtual Assets Guidance (VASP); intercompany/consolidated P-and-L practice (NetSuite, Sage Intacct, PwC).

Ключевые функции: - Реестр контрагентов с ролями own_branch/franchise/agent и AML due-diligence (FATF Rec.14/16) - Спред-модель на точку: сплит спреда 0.1-1% или комиссии 0.1-0.5% - Inter-branch delivery с переоценкой встречного обязательства в USDT - Net-settlement: неттинг позиций по циклам T+1 (hawala) - Float/prefunding по nostro-vostro логике - Affiliate-калькулятор: многоуровневые схемы, post-commit accrual - Прогрессивные бонусы: маржинальные тиры плюс accelerator (30-40%/10-15%) - Statement партнёра, акт сверки, settlement payout USDT/фиат - Consolidated P-and-L с per-branch разрезом и элиминацией intercompany - White-label / agency-vs-principal режим и дашборд прибыльности по точкам

Источники: - https://en.wikipedia.org/wiki/Hawala - https://www.fatf-gafi.org/content/dam/fatf-gafi/guidance/Guidance-RBA-money-value-transfer-services.pdf.coredownload.pdf - https://www.remitso.com/blogs/fatf-compliance-checklist-for-money-transfer-companies - https://www.bitget.com/academy/crypto-otc-desks - https://finerymarkets.com/blog/how-to-launch-a-crypto-otc-desk - https://www.qobra.co/blog/tiered-commission - https://www.level6.com/blog/accelerators-sales-commission-plans/ - https://www.netsuite.com/portal/resource/articles/accounting/intercompany-accounting.shtml - https://www.lorum.com/article/nostro-vostro-loro-clearing-infrastructure - https://ru.beincrypto.com/learn/top-referalnyh-programm-kriptobirzh/

Учёт, леджер, P&L, сверка, расходы и зарплаты

Кратко: Модуль «Учёт, леджер, P&L, сверка» — это финансовое ядро крипто-back-office: двойная запись с USDT как функциональной валютой, мультивалютная переоценка фиата (FX) и крипты (по справедливой стоимости / ASU 2023-08), посменная сверка кассы, трёхуровневая сверка блокчейн↔банк↔внутренний леджер, учёт долгов/депозитов, начисление зарплат и партнёрских комиссий, закрытие периода и экспорт в бухгалтерию. Реализуют его по-разному: мелкий обменник — Google Sheets + ручной P&L; сеть филиалов — внутренний субледжер с разрезом по офисам; институциональный OTC-деск — Bitwave/Cryptio/Cryptoworth поверх NetSuite/SAP с FIFO-lot-tracking и SOC 2. Ключевые риски: незакрытые «брейки» сверки, путаница realized/unrealized, неучтённые сетевые комиссии и долги контрагентов.

Учёт, леджер, P&L, сверка, расходы и зарплаты

Что делает модуль

Это финансовое ядро back-office: единый источник правды о том, сколько денег есть, где они лежат, сколько заработано и кому что должны. Модуль превращает разрозненный поток операций (наличный обмен в офисах, on-chain переводы, фиатные банковские транзакции, расходы, выплаты) в нормализованный двойной леджер, считает прибыль по офисам и за период, сверяет внутренние записи с внешней реальностью (блокчейн, банк, физическая касса) и отдаёт готовые проводки в бухгалтерию. Без него бизнес «знает» прибыль только на глаз — а в крипто-обменнике, где курс плавает внутри дня, а актив учёта (USDT) сам по себе валюта, «на глаз» означает регулярные потери.

Двойная запись и леджер

Базис — double-entry: каждая операция порождает минимум две сбалансированные проводки (дебет = кредит). Для обменника обмен «клиент дал 10 000 USD наличными, получил 9 900 USDT» — это не одна строка, а движение между счётом «Касса USD / офис Анталья», счётом «Кошелёк TRON», счётом дохода (спред) и, возможно, счётом сетевой комиссии. Леджер строится как иерархия счетов (chart of accounts) с обязательными аналитическими разрезами (dimensions): офис/локация, валюта, контрагент, тип операции, смена, кошелёк/банк. Современные крипто-субледжеры (Bitwave, Cryptio, Cryptoworth, SoftLedger) делают именно это: ингестят сырьё из 100+ блокчейнов и бирж, нормализуют и формируют двусторонние journal entries, которые потом агрегатом уходят в GL.

Мультивалютный учёт и переоценка

Здесь две независимые переоценки, которые часто путают:

• FX-переоценка фиата (ASC 830 / IAS 21). Функциональная валюта — USDT (прокси USD). Открытые монетарные балансы в USD/EUR/TRY/UAH (кассы, банковские счета, receivables/payables) на дату отчёта пересчитываются по текущему курсу; разница даёт нереализованную курсовую прибыль/убыток. При фактическом получении/выплате фиксируется реализованная разница. На падающей лире (TRY) это критично: касса в TRY за месяц может «похудеть» на 5–10% в USDT, и без переоценки P&L офиса завышен.
• Переоценка крипты по справедливой стоимости (FASB ASU 2023-08). С отчётных периодов после 15.12.2024 крипто-активы (BTC, ETH; USDT как стейбл обычно близок к 1) измеряются по fair value через прибыль/убыток на каждую отчётную дату, с rollforward-раскрытием. Это заменило старую модель impairment-only. Для расчёта реализованного результата от продажи нужен lot tracking по cost basis — FIFO, LIFO, HIFO, WAC или Spec ID (для США формально признаны FIFO и Spec ID).

Расчёт прибыли (валовая / чистая) по офисам

• Валовая прибыль (спред) = выручка от обмена − стоимость проданной крипты/валюты (cost basis по выбранному методу) − прямые транзакционные издержки (сетевые комиссии gas, комиссии банков/платёжных рельсов). Считается по каждому офису через dimension location.
• Чистая прибыль офиса = валовая − операционные расходы офиса (аренда, зарплаты локального персонала, инкассация, связь) − аллоцированные общие расходы.
• Реализованный P&L vs нереализованный: реализованный — от закрытых сделок; нереализованный — переоценка остатков (FX + fair value). В отчёте CEO их разделяют, иначе резкое движение курса искажает «операционную» картину.

Сравнение офисов делается через сегментный P&L (по-офисный отчёт с одинаковой структурой строк) и контрибуционную маржу.

Расходная часть и категории

Расходы ведутся по дереву категорий, типично: аренда и коммуналка, ФОТ (оклады), премии/бонусы, партнёрские комиссии, сетевые/банковские комиссии, инкассация и логистика наличных, ПО/подписки, юр./комплаенс, маркетинг, потери (over/short, списания, fraud). Каждая категория — отдельный счёт расходов с разрезом по офису. Важна граница CapEx/OpEx и разделение прямых (попадают в валовую маржу) и косвенных расходов.

Зарплаты, премии, партнёрские доли

• Оклады — accrued payroll: расход признаётся в периоде начисления, против него стоит обязательство «Accrued wages / payable», гасится при выплате.
• Премии и profit-share — accrued bonus: дебет «Bonus expense», кредит «Accrued bonus liability»; начисляются по факту достижения базы (часто % от маржи офиса/смены). В US-практике бонус должен быть выплачен в пределах 2.5 мес после конца года, иначе теряет вычитаемость.
• Партнёрские комиссии (affiliate/OTC-партнёры) — это commission accrual (по аналогии с ASC 606 для затрат на привлечение): расход и обязательство признаются в том же периоде, что и сгенерированная партнёром операция, как только сумма исчислима. Для сети партнёров в разных городах ведётся partner ledger (счёт payable на каждого партнёра): начисление доли (например % от объёма/маржи) → накопление → выплата (часто в USDT) → сверка остатка. Post-commit accrual (начисление после подтверждения сделки on-chain) защищает от выплат за развалившиеся сделки.

Сверка (reconciliation) — сердце контроля

Три уровня (минимум 3-way):

1. Source-to-source — запись о выводе с биржи/из системы против on-chain депозита; ключ — transaction hash (≈99.9% точность, нулевой допуск).
2. Source-to-subledger — сырые транзакции против категоризированных записей субледжера.
3. Subledger-to-GL — агрегированные проводки против главной книги.

Методы матчинга: по hash (детерминированно); по timestamp+amount с допусками (типично 60–300 сек по времени, 0.01% по сумме); fee-adjusted (вывод 2.5 ETH − 0.005 gas = депозит 2.495); batch-aggregate (сумма пачки против сеттлмента). Сверяется ~8 полей: время, сумма, актив, комиссия, источник, назначение, hash, классификация.

Кассовая сверка (till / cash drawer) — отдельный, посменный слой для офисов: пересчёт физической наличности на старте смены → отчёт операций → пересчёт на закрытии → разница over/short фиксируется как доход/расход. В нашей модели это «закрытие смены с diff».

Брейки (расхождения): missing tx, дубли, amount mismatch, timestamp divergence, ошибки идентификации токена (wrapped/bridged), мисклассификация internal transfer, cross-chain gaps. Эскалация: авто-правила → ручной разбор → override с документированным обоснованием. KPI зрелой системы: match rate 85–95%, exception aging < 3 дней, close 4–24 ч (continuous) против 3–10 дней (только на конец периода).

Депозиты и долги (receivables / payables)

Обменники постоянно работают в долг: клиент «занёс наличку, заберёт крипту завтра», партнёр получил аванс, контрагент должен за поставку наличных. Это AR/AP-субледжер с aging-отчётом (0–30/30–60/60–90/90+), переоценкой открытых валютных балансов и резервом под сомнительные долги. Клиентские депозиты (предоплата, гарантийные средства) — обязательство, не выручка, пока не оказана услуга.

Закрытие периода и экспорт в бухгалтерию

Период-клоуз по чеклисту: лок проводок в AP/AR/Payroll → загрузка/сверка курсов → начисления (зарплата, бонусы, комиссии, аренда) → FX- и fair-value-переоценка остатков → сверка всех счетов и закрытие брейков → формирование trial balance → корректирующие проводки → блокировка периода → отчёты (P&L по офисам, баланс, cash flow). Экспорт: агрегированные journal entries в QuickBooks / Xero / NetSuite / SAP через нативные коннекторы или API (Bitwave/Cryptio именно так и работают — они субледжер, а GL остаётся в ERP). Подводный камень: QBO/Xero часто не тащат сегментную (по-офисную) детализацию при импорте trial balance — её приходится держать в субледжере.

Как реализуют разные операторы

• Мелкий обменник (1–2 точки): Google Sheets / Excel, ручной дневной блоттер, P&L «выручка минус расходы», переоценка раз в месяц вручную, кассовая сверка по тетради. Дёшево, но хрупко: нет lot-tracking, брейки теряются, TRY-переоценку забывают.
• Сеть филиалов: собственный субледжер (как этот проект — Postgres + RBAC, разрез по офисам, авто-сверка blockchain↔deals со скорингом), посменное закрытие касс, партнёрский леджер, CEO-аналитика с план/факт. GL может оставаться внешним.
• Институциональный OTC-деск: Bitwave / Cryptio / Cryptoworth / SoftLedger поверх NetSuite/SAP, FIFO-lot cost basis, fair value per ASU 2023-08, custodian reconciliation, SOC 2 Type 2 / ISO 27001, continuous reconciliation, многосущностная консолидация, аудиторский след на каждую проводку.

Лучшие практики

• Двойная запись и immutable audit trail с самого начала — не «считать прибыль вычитанием».
• Жёстко разделять realized vs unrealized и FX vs fair-value в отчётности.
• Сверка ежедневно (continuous), не на конец месяца; брейки гасить < 3 дней.
• Сетевые/банковские комиссии — отдельная строка cost basis, не «теряются» в сумме.
• USDT как функциональная валюта, но обязательная FX-переоценка фиатных касс (особенно TRY/UAH).
• Партнёрские/бонусные начисления — accrual в периоде сделки, post-commit, отдельный payable-леджер на контрагента.
• Сегрегация обязанностей: кто оперирует кассой ≠ кто закрывает смену ≠ кто закрывает период.

Типичные ошибки и риски

• Незакрытые/«замятые» брейки сверки → дыры маскируются под прибыль или прячут хищения.
• Игнор сетевых комиссий и проскальзывания → завышенная маржа.
• Путаница realized/unrealized → волатильность курса читается как операционный результат.
• Отсутствие lot-tracking → нельзя корректно посчитать cost basis и налог.
• Депозиты клиентов учтены как выручка → завышенный P&L и кассовый разрыв при возврате.
• Партнёрские доли начислены, но не зарезервированы как payable → «внезапные» выплаты рушат cash flow.
• Ручной Excel без контроля версий и SoD → fraud-риск и невозможность аудита.

Релевантные продукты, стандарты, регуляции

Продукты-субледжеры: Bitwave, Cryptio, Cryptoworth, SoftLedger, TRES Finance, Integral, Coincile; ERP/GL: NetSuite, SAP, QuickBooks, Xero, Sage Intacct; FX-переоценка в Dynamics 365 / Oracle GL / NetSuite. Стандарты: FASB ASU 2023-08 (fair value крипты), ASC 820 (fair value framework), ASC 830 / IAS 21 (валютная переоценка), ASC 606 (costs to obtain a contract — комиссии), GAAP/IFRS, SOC 2 Type 2, ISO 27001. Регуляторное: MSB/VASP-требования, AML/KYC-привязка проводок к контрагентам, налоговый учёт реализованных gain/loss.

Ключевые функции: - Двойная запись (double-entry) с балансировкой дебет=кредит на каждую операцию - Chart of accounts с аналитическими разрезами: офис, валюта, контрагент, смена, кошелёк/банк - Автогенерация двусторонних journal entries из сырых on-chain и кассовых операций - FX-переоценка фиатных балансов (ASC 830/IAS 21) с разделением realized/unrealized - Fair-value переоценка крипто-активов по ASU 2023-08 с rollforward-раскрытием - Lot-tracking cost basis (FIFO/LIFO/HIFO/WAC/Spec ID) для расчёта реализованного результата - Сегментный P&L по офисам: валовая маржа (спред), контрибуция, чистая прибыль - Учёт расходов по дереву категорий (аренда, ФОТ, комиссии, инкассация, потери) - Accrued payroll: начисление окладов с обязательством payable до выплаты - Accrued bonus / profit-share: начисление премий от базы маржи офиса/смены - Partner ledger: начисление и сверка партнёрских комиссий (post-commit accrual, payable на контрагента) - 3-way reconciliation: source-to-source, source-to-subledger, subledger-to-GL - Матчинг по transaction hash, timestamp+amount с допусками, fee-adjusted, batch-aggregate - Кассовая (till) сверка посменно с фиксацией over/short - Управление брейками: классификация, очередь ручного разбора, override с обоснованием - AR/AP субледжер с aging-отчётом и резервом под сомнительные долги - Учёт клиентских депозитов как обязательства (не выручки) до оказания услуги - Period close по чеклисту: лок проводок, начисления, переоценка, trial balance, блокировка периода - Экспорт агрегированных проводок в QuickBooks/Xero/NetSuite/SAP через API/коннекторы - KPI-мониторинг сверки: match rate, exception rate, exception aging, time-to-close

Источники: - https://softledger.com/crypto-accounting-software - https://cryptio.co/ - https://www.bitwave.io/solutions/crypto-subledger - https://www.bitwave.io/blog/crypto-cost-basis-tracking - https://www.cryptoworth.com/blog/crypto-transaction-reconciliation-tools - https://breezing.io/blog/best-crypto-accounting-subledger-tools/ - https://thecfoclub.com/tools/best-blockchain-accounting-software/ - https://finchtrade.com/blog/reconciliation-tools-for-multi-layer-crypto-operations - https://cryptobackoffice.com/ - https://www.crowe.com/insights/take-into-account/fasb-to-finalize-fair-value-guidance-for-crypto-assets - https://www.withum.com/resources/navigating-the-fasbs-crypto-asset-rules-valuation-and-reporting-implications/ - https://www.cryptoworth.com/blog/fasb-asu-2023-08 - https://dart.deloitte.com/USDART/home/publications/deloitte/heads-up/2023/fasb-issues-asu-crypto-assets - https://softledger.com/blog/foreign-currency-revaluation-definition-process-and-examples - https://learn.microsoft.com/en-us/dynamics365/finance/cash-bank-management/foreign-currency-revaluation-accounts-payable-accounts-receivable - https://www.accountsiq.com/blog/fx-revaluations-explained - https://coincile.io/learn/reconciliation/ - https://tres.finance/multi-source-reconciliation-powered-by-ai-built-for-scale/ - https://optimus.tech/blog/crypto-reconciliation-guide-for-finance-teams - https://www.cointracker.io/blog/wallet-reconciliation - https://www.accountingtools.com/articles/what-is-a-cash-reconciliation.html - https://www.netsuite.com/portal/resource/articles/accounting/cash-reconciliation.shtml - https://coinledger.io/blog/cryptocurrency-tax-calculations-fifo-and-lifo-costing-methods-explained - https://www.cryptoworth.com/blog/unrealized-gain-loss-calculations - https://www.accountingtools.com/articles/commission-expense-accounting - https://www.everstage.com/sales-commission/sales-commission-accounting - https://www.patriotsoftware.com/blog/accounting/accrued-bonus/ - https://www.adp.com/resources/articles-and-insights/articles/a/accrued-payroll.aspx - https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_N1455781.html - https://ramp.com/blog/month-end-close-process

Аналитика, BI, дашборды, KPI

Кратко: Detailed industry-research section on the Analytics/BI/Dashboards/KPI module for fintech and crypto back-office systems, covering CEO dashboards, the KPI canon (turnover/profit/margin/average ticket), plan-vs-actual variance, dimensional cuts by office/manager/channel, client analytics (RFM, cohorts, retention/churn, concentration), forecasting, and anomaly alerting. It contrasts how a small exchanger, a branch network, and an institutional OTC desk each implement these, names concrete vendors and standards, and lists best practices and common failure modes. All figures and patterns are sourced from active web research (RU+EN).

Аналитика, BI, дашборды и KPI в крипто/финтех back-office

Что делает модуль

Аналитический модуль превращает сырой поток сделок (наличные обмены, онлайн-OTC, фиат-каналы, on-chain движения USDT) в управленческую картину: сколько прокрутили, сколько заработали, где маржа течёт, какой офис/менеджер/канал тащит или проседает, кто из клиентов растёт, а кто отваливается. Технически это слой над операционной БД и блокчейн-данными: ETL/трансформации → семантический слой (metrics layer) с едиными определениями метрик → визуализация (дашборды) + алёрты + прогнозы. Ключевая ценность не в графиках, а в том, что «оборот», «прибыль» и «маржа» считаются одинаково во всех отчётах — иначе CEO и руководитель офиса спорят о цифрах вместо решений.

Канон KPI (детально)

Для money-services/обменника ядро метрик:

• Оборот (Volume / Turnover) — суммарный номинал сделок за период в единой валюте учёта (USDT). Разбивается на buy/sell, по активам (USDT/BTC/ETH), по направлению cash↔crypto и crypto↔fiat.
• Прибыль (Gross Profit / спред-доход) — сумма по сделкам (цена клиента − базовая котировка) × объём. В OTC спред типично 0.1–1%, в виде явной комиссии — 0.1–0.5% (Bitget).
• Маржа (%) = прибыль / оборот. Главный KPI здравости: падение маржи при росте оборота = демпинг или утечка курса.
• Средний чек (Average Transaction Value, ATV) = оборот / число сделок. Бенчмарки: $800–1 500 у «розницы/туристов», >$10 000 у бизнес-клиентов (FinModelsLab).
• Operating Expense Ratio (OER) = опер. расходы / выручка. Цель зрелого процессора — 45–55%, ранняя стадия часто 70%+.
• Net Interest Margin / Cost of Funds — если есть фондирование/удержание ликвидности, NIM целевой 25–40%, CoF должен быть существенно ниже NIM.
• Months-to-breakeven — «<24 мес — сильно» для цифровых финтех-платформ.

Правило компоновки CEO-дашборда: 12–20 KPI всего, 3–5 на категорию — больше создаёт шум, меньше оставляет слепые зоны (Qlik, Atlassian).

План/факт (variance analysis)

База любого variance — разница факта и предопределённого ориентира (бюджет/план/rolling forecast); favorable = лучше плана, unfavorable = хуже (WallStreetPrep). Зрелая практика — не «факт vs бюджет», а факт vs последний прогноз vs прошлый год vs предыдущий период, чтобы отделить сезонность и тайминг от реального недобора (Lumel, Farseer). Визуализация: bar/column (план vs факт по категориям), trend-линии вариаций, heat-map с цветовой подсветкой крупных отклонений. Если по статье вариация стабильно, например, +7% к бюджету — её закладывают в будущий прогноз.

Разрезы: офисы / менеджеры / каналы

Дашборд должен резать одни и те же метрики по измерениям: офис (Анталья/Аланья), менеджер/кассир, канал (наличный офис / онлайн-OTC через партнёров / украинский фиат-ФОП), актив, валютная пара, смена. Это даёт: - рейтинг офисов по марже и обороту, выявление офиса с аномально низким спредом; - KPI менеджеров (оборот, маржа на смене, средний чек, число сделок, расхождения при закрытии кассы); - вклад каналов в прибыль и их разная экономика (партнёрский OTC несёт комиссию партнёра → ниже net-маржа).

Клиентская аналитика

• RFM (Recency, Frequency, Monetary) — сегментация клиентов; высокий Recency + низкая Frequency/Monetary = риск оттока; «чемпионы» vs «спящие» vs «потерянные» под разные кампании удержания (CleverTap, MoEngage).
• Когорты — группировка по месяцу первой сделки, отслеживание удержания/оборота по «возрасту» когорты. В финансах нашли: клиенты, прожившие >18 мес, дают в 3.2× больший средний объём, чем отвалившиеся в первый год (Careery).
• Отток (churn) — для карточного бизнеса нормальная годовая аттриция 15–25%; считается по когортам, а не «в среднем по больнице».
• Концентрация — доля топ-N клиентов в обороте/прибыли (Парето, индекс концентрации). Критично для риск-менеджмента: 3 клиента = 60% оборота это операционный и комплаенс-риск.
• Рост/win-back — динамика per-client объёма, реактивация спящих.

Прогнозирование

• ARIMA/SARIMA/Holt-Winters — чистые регулярные ряды и одиночная сезонность (MAPE ~3–14%).
• Prophet (Meta) — бизнес-ряды с праздниками, пропусками, выбросами и несколькими сезонными циклами (MAPE 2.2–24%).
• Гибрид ARIMA+Prophet / LSTM — для сложной нелинейности (ScienceDirect, MCP Analytics).

Прикладное в обменнике: прогноз спроса на наличность по офисам (cash demand planning, чтобы не было кассовых разрывов), прогноз оборота/выручки для план/факта, прогноз потребности в пополнении USDT-кошельков.

Алёрты на аномалии

Современный стек добавляет AI/ML anomaly detection поверх дашбордов: Power BI (streaming + авто-обновление + встроенный anomaly detection), Klipfolio (push-алёрты на скачки расходов/провалы выручки), BigQuery ML + Looker, специализированные MindBridge/ThetaRay/NetGuardians/Anodot для финтранзакций с risk-scoring и реал-тайм мониторингом (Lucid, Anodot, Fraud.net). Для обменника типовые алёрты: маржа офиса ниже порога, расхождение кассы при закрытии смены, on-chain баланс ≠ учётному, скачок объёма у одного клиента (AML/structuring), курс менеджера вне коридора, обрыв синхронизации блокчейна.

Как реализуют разные операторы

• Мелкий обменник — Google Sheets/Excel + сводные таблицы, иногда Looker Studio поверх. Дёшево, но метрики не унифицированы, нет алёртов, нет on-chain сверки.
• Сеть филиалов — собственная БД (Postgres) + дашборд-приложение/Metabase/Superset, разрезы по офисам/менеджерам, RBAC по ролям, план/факт, ETL из касс и кошельков. Нужен семантический слой (dbt MetricFlow / metrics store) чтобы «оборот» считался одинаково везде (dbt, Improvado).
• Институциональный OTC-деск — платформы Talos, Finery Markets, FinchTrade: реал-тайм и историческая рыночная дата, TCA (transaction cost analysis), агрегация позиций/балансов/PnL/exposure из нескольких прайм-брокеров и бирж в один дашборд; Nansen для on-chain PnL и Smart-Money attribution (Talos, Finery, Nansen).

Лучшие практики

• Один governed источник истины для метрик (metrics-as-code, версионирование, изменения через PR — «можно объяснить, когда и почему KPI поменялся»).
• Functional currency на уровне сущности, presentation currency (USDT) на уровне группы — отделять FX-движение от торговой прибыли.
• Drill-down от CEO-уровня к офису/менеджеру/сделке; самокритичный «board pack» с объяснением вариаций.
• Реал-тайм только там, где он нужен (касса, on-chain), остальное — батч.

Типичные ошибки и риски

• Vanity metrics — «дашборд зелёный, а денег нет»: смотрят на оборот, игнорируя маржу после всех комиссий.
• Несогласованные определения метрик между отчётами → потеря доверия к цифрам.
• Усреднённый churn вместо когортного — маскирует проблему удержания новых клиентов.
• Перегруз дашборда (>20 KPI) → шум.
• Отсутствие сверки учёт↔блокчейн → прибыль на дашборде расходится с реальными балансами.
• Прогноз без сезонности/праздников в bizdata → систематический промах.

Ключевые функции: - CEO-дашборд с 12–20 KPI (3–5 на категорию) и drill-down от группы к офису/сделке - Расчёт оборота/прибыли/маржи/среднего чека в единой валюте учёта (USDT) с разбивкой buy/sell и по активам - Семантический слой (metrics-as-code, dbt MetricFlow) — единый источник истины для определений KPI - План/факт variance analysis (favorable/unfavorable) с heat-map отклонений - Многомерные сравнения: факт vs бюджет vs прогноз vs прошлый год vs предыдущий период - Разрезы метрик по офисам, менеджерам/кассирам, каналам, валютным парам, сменам - Рейтинг и KPI менеджеров (оборот, маржа на смене, средний чек, расхождения кассы) - RFM-сегментация клиентов (Recency/Frequency/Monetary) под кампании удержания - Когортный анализ удержания и оборота по месяцу первой сделки - Расчёт оттока (churn) по когортам и win-back спящих клиентов - Анализ концентрации клиентов (Парето, доля топ-N в обороте/прибыли) для риск-менеджмента - Прогнозирование оборота/выручки (Prophet/ARIMA/SARIMA, гибриды) с учётом сезонности и праздников - Прогноз спроса на наличность по офисам (cash demand planning) и пополнения USDT-кошельков - AI/ML anomaly detection и push-алёрты (скачок объёма клиента, маржа ниже порога, AML structuring) - Сверка учёт↔блокчейн с алёртом при расхождении on-chain баланса и учётного - Net Interest Margin / Operating Expense Ratio / Cost of Funds для оценки операционной эффективности - TCA (transaction cost analysis) и PnL/exposure-аналитика для OTC-исполнения - Реал-тайм streaming-дашборды (касса, on-chain) + батч для исторической аналитики - Multi-currency reporting: functional currency на уровне сущности, presentation currency на группе - Версионирование изменений метрик через PR (audit «когда и почему KPI поменялся»)

Источники: - https://www.qlik.com/us/dashboard-examples/financial-dashboards - https://www.atlassian.com/data/business-intelligence/how-to-build-a-ceo-dashboard - https://financialmodelslab.com/blogs/kpi-metrics/online-currency-exchange - https://www.bitget.com/amp/academy/crypto-otc-desks - https://www.talos.com/ - https://finerymarkets.com/otc-desks.html - https://nansen.ai/ - https://www.moengage.com/blog/growth-tactic-1-how-to-use-cohort-analysis-to-measure-customer-retention/ - https://careery.pro/insights/churn-rate-analysis-complete-guide-from-financial-analyst - https://clevertap.com/blog/rfm-analysis/ - https://www.wallstreetprep.com/knowledge/budget-actual-variance-analysis-fpa/ - https://lumel.com/blog/planning/variance-analysis-actual-budget-forecast/ - https://www.farseer.com/blog/budget-vs-actual/ - https://www.lucid.now/blog/best-tools-real-time-financial-dashboards/ - https://www.anodot.com/learning-center/top-8-ai-powered-anomaly-detection-tools-for-time-series-data/ - https://www.fraud.net/resources/best-tools-for-real-time-transaction-monitoring - https://www.getdbt.com/product/semantic-layer - https://improvado.io/blog/what-is-a-metrics-layer - https://www.sciencedirect.com/science/article/pii/S2590123025017748 - https://mcpanalytics.ai/articles/arima-vs-prophet-forecasting-method-comparison - https://makstroyirk.ru/dashbord-finansovyh-kpi-polnyj-gajd-po-vizualizaczii-i-analitike/ - https://vc.ru/marketplace/2891530-kpi-otdela-marketpleysov-kak-upravlyat-pribylyu

Коммуникации, Telegram/мессенджер-боты, уведомления, портал

Кратко: Раздел детально разбирает модуль «Коммуникации, боты, уведомления, портал» для крипто-back-office: омниканальный слой (Telegram/WhatsApp/email/SMS), клиентские и менеджерские Telegram-боты, приём заявок и RFQ через бота, статус/курс-уведомления, личный кабинет-портал, шаблоны сообщений и мониторинг чатов менеджеров. Опираясь на Telegram Bot API 9.x, WhatsApp HSM-механику (24-часовое окно, opt-in) и практику OTC-десков (Kraken, Binance, Liquid Mercury), показано как это реализуют мелкий обменник, сеть филиалов и институциональный деск, с акцентом на риски off-channel и кейсы штрафов SEC/CFTC на 2+ млрд долларов.

Коммуникации, Telegram/мессенджер-боты, уведомления, портал

Назначение модуля

Этот модуль — нервная система клиентского взаимодействия back-office. Он отвечает за то, чтобы каждое касание клиента (заявка на обмен, согласование курса, подтверждение реквизитов, уведомление о зачислении, запрос статуса) проходило через контролируемые, логируемые каналы, а не терялось в личных перепиской менеджеров. Для сети наличных обменников и OTC-десков именно мессенджеры (а не сайт) являются основным каналом сделки, поэтому бот и омниканальный слой — не «фича», а ядро операционного процесса. Модуль одновременно обслуживает три аудитории: клиентов (заявки, котировки, статусы), менеджеров/кассиров (приём и проведение заявок из бота, уведомления о новых сделках), и комплаенс/руководство (надзор за чатами, архив переписки).

Ключевые функции (детально)

1. Омниканальный inbox. Все входящие из Telegram, WhatsApp Business, web-чата, email, SMS и соцсетей сводятся в единую очередь с привязкой к карточке клиента (Deal/Client в CRM). Каждое сообщение получает channel, direction, thread_id и assigned_manager. Это даёт сквозную историю общения и позволяет передавать диалог между менеджерами без потери контекста.

2. Клиентский Telegram-бот. Реализуется на Telegram Bot API (актуально API 9.x, 2026): inline-клавиатуры для выбора направления/актива, deep-links (t.me/bot?start=ref_xxx) для атрибуции партнёра, Web Apps (mini-app внутри Telegram) для сложных форм заявки, и webhook вместо polling для продакшна. Бот ведёт пользователя по сценарию «направление → актив → сумма → реквизиты → подтверждение котировки», формируя заявку в CRM. Все возможности Bot API (платежи, inline, web apps) бесплатны.

3. Приём заявок и RFQ. Для розницы — простая заявка с фиксированным/обновляемым курсом. Для OTC — модель Request-for-Quote: клиент запрашивает котировку на блок, деск отвечает ценой с ограниченным TTL (на портале минимум ~10 сек, для RFQ окно длиннее), клиент акцептует до истечения. Движок обязан трекать срок жизни котировки и блокировать исполнение истёкших. Продвинутые десdki поддерживают multi-leg RFQ — пакет сделок одной котировкой.

4. Менеджерский/кассирский бот. Зеркальный бот для персонала: пуш о новой заявке со ссылкой на сделку и ключевыми данными клиента, кнопки «Взять в работу / Подтвердить курс / Отклонить / Закрыть», ввод суммы выданной наличности, фиксация результата прямо из чата (визирование). Это критично для филиальной сети — кассир в Анталье не заходит в админку, а работает из Telegram.

5. Уведомления о статусах и курсах. Событийные триггеры: «заявка принята», «курс зафиксирован», «крипта получена on-chain», «наличные готовы к выдаче», «сделка закрыта». Отдельный класс — rate alerts: подписка на курс (например, USDT/TRY достиг порога) с passive-режимом (планировщик каждые N минут сверяет курс) или active (по команде). Каналы доставки — Telegram-пуш, email, SMS, webhook.

6. Клиентский личный кабинет/портал. Web-портал (часто дублирует бота) с историей сделок, статусами, реквизитами, выгрузкой документов, для OTC — RFQ-интерфейсом и API-доступом. Институциональные клиенты выбирают между GUI и API-интеграцией в свои системы; розница — между ботом и кабинетом.

7. Шаблоны сообщений. Версионируемая библиотека шаблонов с подстановками ({client_name}, {amount}, {rate}, {office}) и локализацией (RU/TR/UK/EN). Для WhatsApp — обязательные HSM-шаблоны, заранее одобренные Meta: вне 24-часового сервисного окна бизнес может писать только утверждёнными шаблонами и только при наличии opt-in. Шаблоны не должны запрашивать номера карт/счетов — это нарушение политики WhatsApp.

8. Мониторинг чатов менеджеров. Архивирование и надзор за деловой перепиской: алерты на риск-паттерны (увод клиента в личку, обещание курса вне системы, утечка реквизитов), запись всех сообщений в неизменяемый архив. Это прямой ответ на регуляторный риск off-channel communications.

Модель данных (сущности)

• Channel — тип канала, токен/credentials, статус, привязка к офису.
• Conversation/Thread — диалог: client_id, channel, manager_id, status, last_activity.
• Message — body, direction, sender, timestamp, attachments, template_id, delivery_status (sent/delivered/read/failed).
• MessageTemplate — code, language, body с плейсхолдерами, версия, статус одобрения (для WhatsApp — Meta approval state).
• NotificationSubscription — client_id, event_type или rate-condition, channel, enabled.
• BotSession — chat_id, state машины сценария, current_step, context.
• Quote/RFQ — pair, side, amount, price, valid_until, status (active/accepted/expired).
• ConsentRecord — opt-in/opt-out по каналам с timestamp (юридическое основание рассылок).

Рабочие процессы

1. Заявка через бота: start → выбор параметров → котировка с TTL → акцепт → создание Deal → роутинг на офис/менеджера → менеджерский пуш → проведение → статус-уведомления клиенту до закрытия.
2. Эскалация бот→человек: при нераспознанном намерении или явном запросе («оператор») — handoff в омниканальный inbox с сохранением контекста; SLA на ответ.
3. Rate alert: клиент подписывается → планировщик сверяет курс → при срабатывании пуш + предложение оформить сделку в один тап.
4. Broadcast: сегментированная рассылка (новый курс, акция) строго по opt-in и через одобренные шаблоны.

Как реализуют разные операторы

• Мелкий обменник: один Telegram-бот + ручной перевод диалогов; шаблоны в Google Sheets; уведомления через amoCRM/HelpDeskEddy-интеграции. Дёшево, но переписка часто в личных аккаунтах — главный риск.
• Сеть филиалов (этот бизнес): омниканальная CRM, клиентский + кассирский боты, роутинг по офисам (Анталья/Аланья/онлайн/UA-ФОП), партнёрская атрибуция через deep-links, мониторинг чатов менеджеров. Баланс скорости и контроля.
• Институциональный OTC-деск (Kraken, Binance, WhatBIT, софт типа Liquid Mercury/Finery): client portal + RFQ + API, котировки с TTL, multi-leg, pre-trade риск-контроли, settlement-автоматизация, выделенный chat с трейдером деска под полным архивом.

Лучшие практики

• Webhook + idempotency для ботов; конечный автомат состояний на сессию.
• Все деловые коммуникации только в управляемых каналах; никаких личных аккаунтов.
• Версионирование и локализация шаблонов; A/B на доставляемость.
• Чёткий human-handoff с SLA; бот не должен зацикливать клиента.
• Явный opt-in/opt-out и журнал согласий (ConsentRecord).
• Идемпотентные уведомления (не слать дубль при ретрае события).

Типичные ошибки и риски

• Off-channel communications — главный комплаенс-риск: SEC/CFTC с 2021 г. взыскали 2+ млрд долл. с 100+ фирм за неархивированную переписку в WhatsApp/Signal/Telegram (Wells Fargo — 125 млн долл.). Личные мессенджеры менеджеров = неконтролируемый канал.
• Нарушение политики WhatsApp (запрос реквизитов/карт в шаблоне → бан номера).
• Рассылки без opt-in → блокировка канала и штрафы за спам.
• Исполнение по истёкшей котировке (нет TTL-контроля) → ценовые убытки.
• Утечка реквизитов/PII в чатах, фишинг через подмену бота (важна верификация официального бота).

Релевантные продукты и стандарты

Telegram Bot API (9.x, Web Apps, Payments API, Business Mode), WhatsApp Business Cloud API + HSM/Meta-approval, омниканальные CRM (amoCRM, OkoCRM, okdesk, Sinch/Infobip как BSP), OTC-софт (Liquid Mercury, Finery Markets), surveillance-платформы (LeapXpert, Global Relay) для архива и надзора; регуляторика — SEC Rule 17a-4 / FINRA recordkeeping, GDPR/локальные требования к opt-in.

Ключевые функции: - Омниканальный inbox: сведение Telegram/WhatsApp/email/SMS/web-чата в единую очередь с привязкой к карточке клиента - Клиентский Telegram-бот на Bot API 9.x: inline-клавиатуры, deep-links для партнёрской атрибуции, Web Apps mini-app, webhook - Сценарий приёма розничной заявки (направление→актив→сумма→реквизиты→подтверждение курса) с созданием Deal в CRM - RFQ-механика для OTC: запрос котировки на блок, ответ с TTL, акцепт до истечения, multi-leg пакеты - Контроль срока жизни котировки (valid_until) и блокировка исполнения истёкших quote - Менеджерский/кассирский бот: пуш о новой заявке, кнопки взять/подтвердить курс/отклонить/закрыть, визирование из чата - Событийные статус-уведомления (принято / курс зафиксирован / крипта on-chain / наличные готовы / закрыто) - Rate-alerts: подписка на пороговый курс, passive-планировщик и active-режим, пуш с предложением сделки в один тап - Клиентский личный кабинет/портал: история сделок, статусы, документы, для OTC — RFQ-интерфейс и API-доступ - Библиотека версионируемых шаблонов сообщений с плейсхолдерами и локализацией RU/TR/UK/EN - WhatsApp HSM-шаблоны: соблюдение 24-часового окна, отправка вне окна только одобренными Meta шаблонами - Управление opt-in/opt-out и журнал согласий (ConsentRecord) как основание рассылок - Сегментированный broadcast (новый курс, акции) строго по opt-in и через одобренные шаблоны - Эскалация бот→человек (human handoff) с сохранением контекста и SLA на ответ - Мониторинг чатов менеджеров: архив переписки, алерты на увод клиента в личку / обещание курса вне системы - Неизменяемое архивирование всех деловых коммуникаций для комплаенса (anti off-channel) - Конечный автомат состояний бот-сессии (BotSession state machine) с idempotency на webhook - Доставка с трекингом статуса (sent/delivered/read/failed) и идемпотентные ретраи уведомлений - Партнёрская атрибуция входящих клиентов через Telegram deep-link start-параметры - Telegram Payments API / приём оплаты и подтверждение реквизитов внутри чата

Источники: - https://www.antiersolutions.com/blogs/how-to-launch-a-telegram-based-otc-trading-platform-in-2026/ - https://www.bitget.com/wiki/telegram-bot-crypto-payment - https://core.telegram.org/bots/api - https://core.telegram.org/bots/payments - https://telegram-group.com/en/blog/telegram-bots-api-2026-complete-guide-creating-your-first-bot/ - https://www.kraken.com/institutions/otc - https://crypto.com/us/crypto/learn/what-is-crypto-otc-trading-how-does-it-work - https://www.liquidmercury.com/resources/crypto-otc-desk-software - https://finerymarkets.com/blog/how-to-launch-a-crypto-otc-desk - https://pixelplex.io/blog/otc-crypto-exchange-development/ - https://www.smsmode.com/en/whatsapp-business-api-customer-care-window-ou-templates-comment-les-utiliser/ - https://business.whatsapp.com/policy - https://www.infobip.com/docs/whatsapp/compliance/template-compliance - https://www.mayerbrown.com/en/insights/publications/2024/02/whatsapp-all-over-again-the-sec-brings-more-recordkeeping-charges-against-broker-dealers-and-investment-advisers-for-off-channel-communications - https://www.leapxpert.com/secs-500m-fines-in-2024-the-cost-of-messaging-non-compliance/ - https://okocrm.com/blog/chto-takoe-omnikanalnyj-chat/ - https://okdesk.ru/blog/telegram-bot/ - https://bizandsoft.ru/vidzhety-amo/uvedomleniya-v-telegram - https://coinmarketcap.com/chatbot/ - https://cryptocurrencyalerting.com/bot/telegram

Безопасность, роли/доступы, аудит, антифрод

Кратко: Подробный отраслевой раздел по направлению «Безопасность, роли/доступы, аудит, антифрод» для back-office систем наличных крипто-обменников и OTC-десков. Покрывает RBAC и 5 базовых ролей, сегрегацию обязанностей, неизменяемый аудит-лог, защиту от внутреннего мошенничества и сговора кассиров, 2FA/MFA, лимиты и maker-checker апрувы, маскирование чувствительных данных и физическую безопасность офиса — с конкретными вендорами, стандартами (NIST 800-53, PCI DSS, SEC 17a-4), цифрами и реальными кейсами (Bybit, инсайдерский сговор на $200M).

Безопасность, роли/доступы, аудит, антифрод

Что делает модуль

Модуль безопасности — это «нервная система» back-office обменника. Он отвечает на четыре вопроса по каждому действию: кто (аутентификация и идентичность), что ему можно (авторизация/RBAC), что он реально сделал (аудит-лог) и не выглядит ли это как мошенничество (антифрод-мониторинг). В контексте наличного крипто-бизнеса (офисы Анталья/Аланья + сеть OTC-партнёров + украинский фиат-ФОП), где через одну кассу за день проходят десятки тысяч долларов наличными и эквивалент в USDT, этот модуль — главная преграда между бизнесом и двумя угрозами: внешним взломом и внутренним мошенничеством кассиров/менеджеров (по статистике именно инсайдеры наносят финансово больше всего ущерба MSB-бизнесу).

RBAC и ролевая модель

Ядро — Role-Based Access Control (RBAC): права привязываются не к человеку, а к роли; человек получает роль (или набор ролей). Базовая модель из 5 ролей для обменника:

• admin / superadmin — управление пользователями, ролями, лимитами, конфигом. НЕ должен иметь права проводить или утверждать денежные операции (иначе администратор = единая точка тотального контроля).
• manager (руководитель офиса) — заводит сделки, утверждает операции в рамках лимита, видит аналитику своего офиса, закрывает смены. Управляет, но не «трогает кассу» сам.
• accountant / финмониторинг — сверка, отчётность, выгрузки, read-write по бухгалтерским сущностям, но без права инициировать выплату клиенту.
• cashier / teller — создаёт операции приёма/выдачи наличных и крипты, ведёт свою смену. Видит только свою кассу, не видит чужие, не меняет курсы и лимиты.
• viewer / auditor — только чтение, для собственника, внутреннего аудита, внешнего ревизора.

Лучшая практика — least privilege (NIST 800-53 AC-6): по умолчанию запрет, права выдаются точечно под задачу. Права лучше делать scoped — не просто «cashier», а «cashier@Antalya-office». Для OTC-партнёров в других городах — отдельный tenant/scope, чтобы партнёр видел только свои сделки и баланс. В крипто-периметре RBAC материализуется в multisig-кошельках: разные ключи у разных функций, M-of-N подписей для движения средств.

Сегрегация обязанностей (SoD)

Принцип: ни один человек не может в одиночку пройти полный цикл «инициировать → утвердить → исполнить → отразить в учёте». Классическое правило — кто создал операцию, тот не может её утвердить; кто ведёт кассу, тот не сверяет её остаток. Это прямой барьер против и ошибок, и фрода. Конкретные SoD-конфликты для обменника, которые система должна блокировать на уровне ролей:

• Кассир создаёт выдачу крипты и сам же подтверждает отправку on-chain.
• Менеджер заводит «клиента» (контрагента-получателя) и утверждает выплату на его адрес.
• Один человек закрывает смену и утверждает расхождение (variance) по кассе.
• Администратор меняет лимит и проводит операцию сверх старого лимита.

Аудит-лог (immutable audit trail)

Каждое значимое действие пишется в append-only, неизменяемый журнал: кто, что, когда (timestamp, синхронизированный с авторитетным источником времени), старое и новое значение, успех/отказ, IP/устройство. Лог должен быть защищён от подмены даже администратором БД. Реализации:

• Hash-chaining: каждая запись содержит криптографический хэш предыдущей; правка любой записи рвёт цепочку и выдаёт факт вмешательства. Так делает Stripe.
• WORM-хранилище (write-once-read-many) — требование SEC Rule 17a-4 для брокеров-дилеров; запись нельзя перезаписать или стереть.
• Anchoring: периодический якорь хэша лога в блокчейн для внешнего доказательства целостности.

Что обязательно логировать в обменнике: вход/выход, смену пароля/2FA, создание и изменение сделки/операции, изменение курса и лимита, утверждение/отклонение апрува, открытие/закрытие смены, экспорт данных, любую попытку доступа с отказом, движение крипты (инициация подписи, broadcast). Логи нужно хранить отдельно от прод-БД, с ограниченным и самим же аудируемым доступом на чтение.

Антифрод и защита от сговора кассиров

Сговор (collusion) — самый опасный сценарий: два кассира или кассир+менеджер обходят SoD. Контрмеры:

• Maker-checker / four-eyes с тиерами по сумме: операция ниже порога — автопроведение; средняя — один апрувер; крупная (например, > эквивалента $10–50k) — второй уровень апрува или подпись собственника. Логика прямо как в финтех-воркфлоу: система сама сверяет сумму с политикой.
• Ротация апруверов и кассиров — периодическая смена связки «кто кого утверждает» ломает устойчивые сговоры (рекомендация банков по борьбе с коллузией).
• Cash-count / till reconciliation: обязательная сверка остатка кассы при открытии и закрытии смены под dual custody (двое пересчитывают), фиксация variance, эскалация расхождений независимому контролёру.
• AML transaction monitoring: правила на structuring/smurfing (дробление под порог), velocity (аномальное число/объём операций за окно), гео-риск, риск-контрагента. Для крипты — KYT (Chainalysis, Elliptic): скоринг входящих депозитов, флаг средств из санкционных/миксер-источников.
• Поведенческие алерты: кассир систематически даёт курс хуже стандартного и разницу кладёт в карман; повышенная доля «отменённых» операций; операции вне рабочих часов; повторяющийся один и тот же «клиентский» адрес.

Реальные кейсы подтверждают важность: при взломе Bybit (фев. 2025, ~$1.5 млрд) multisig не спас, потому что был скомпрометирован фронтенд подписи — урок про защиту самого процесса апрува, а не только числа подписей. В кейсе 2019 года руководитель биржи вступил в сговор и утвердил несанкционированный вывод $200 млн — иллюстрация, почему один из подписантов multisig должен быть внешней стороной, а ключи — мониториться.

2FA / MFA

MFA обязателен для всех привилегированных и внешне доступных аккаунтов (NIST 800-53 IA-2). Иерархия стойкости по NIST SP 800-63B: phishing-resistant факторы (FIDO2/WebAuthn аппаратные ключи, PIV-смарт-карты) — верхний уровень для admin/manager; TOTP-приложения — допустимо; SMS/voice/push — слабее (SIM-swap, перехват, push-bombing) и должны выводиться из употребления для привилегированных ролей. Для операций сверх лимита — step-up аутентификация (повторный фактор именно в момент апрува, а не только при входе).

Маскирование чувствительных данных

Dynamic Data Masking (DDM) — поле маскируется в реальном времени по роли смотрящего. Кассир видит телефон клиента как +90 5•• ••• •• 34, полный номер — только у комплаенс/руководителя с обоснованной потребностью. По аналогии с PCI DSS (показывать максимум первые 6 / последние 4 цифры PAN) — для обменника маскируют телефон, паспортные данные, полный адрес кошелька клиента, ФИО партнёра. Принципы: маскирование на уровне поля, по RBAC, в логах и отчётах тоже (чтобы PII не утекало через выгрузки); опционально токенизация/шифрование «at rest». Вендоры: Protegrity, IRI, Strac.

Физическая + ИБ безопасность офиса

Цифровые контроли бессмысленны без физических, когда в офисе лежит наличность:

• Dual control / joint custody сейфа: замок с двумя комбинациями, никто не знает обе — сейф открывается только вдвоём.
• CCTV на кассу и сейф, запись при любом доступе, особенно вне часов; tamper-evident пломбы.
• Разделение зоны клиента и зоны хранения; контроль доступа в back-office (карты/биометрия с логом).
• ИБ-периметр: рабочие станции кассиров без права ставить ПО, без USB, VPN до back-office, сегментация сети, отдельная сеть для кошельковой инфраструктуры; cold storage офлайн.

Как это делают разные операторы

• Мелкий обменник (1–2 точки): RBAC из 3–4 ролей в самой CRM, maker-checker на ручном уровне («владелец смотрит крупные»), аудит-лог в БД, 2FA через TOTP, dual-control сейф. Главный риск — владелец совмещает роли admin+manager+cashier и убивает SoD.
• Сеть филиалов: scoped-роли по офисам, централизованный неизменяемый аудит, тиерные лимиты, ротация апруверов, ежесменная сверка кассы, AML-мониторинг, DDM, SIEM поверх логов.
• Институциональный OTC-деск: строгий SoD по подразделениям (front/middle/back office), maker-checker на каждой выплате, multisig с внешним подписантом, HSM для ключей, phishing-resistant MFA, формальные политики под NIST 800-53 / SOC 2, KYT-скоринг каждой транзакции, выделенная функция compliance с правом блокировки.

Типичные ошибки и риски

• «Бог-админ» с правом и менять конфиг, и проводить деньги — единая точка отказа.
• Общие учётки («касса1») — убивают персональную атрибуцию в аудите.
• Аудит-лог в той же БД с правом правки у админа — не immutable.
• Лимиты только при входе, а не на каждую операцию (step-up отсутствует).
• PII в выгрузках/логах без маскирования.
• Multisig «для галочки», где все ключи у инсайдеров (нет внешнего подписанта).
• Нет ротации апруверов → устойчивый сговор кассир+менеджер.

Стандарты и регуляции

NIST SP 800-53 (AC-6 least privilege, IA-2 MFA, AU-* аудит), NIST SP 800-63B (уровни аутентификаторов), PCI DSS 4.0 (маскирование, RBAC, логирование), SEC Rule 17a-4 / FINRA CAT (WORM, точность таймстампов), BSA/AML для MSB (пороги, мониторинг, SAR), SOC 2 (контроли доступа и аудита). Вендоры/инструменты: Chainalysis/Elliptic (KYT), Hawk/Sumsub (AML-мониторинг), Protegrity/Strac/IRI (маскирование), FIDO2/YubiKey (MFA), HSM (хранение ключей).

Ключевые функции: - RBAC с scoped-ролями (admin/manager/accountant/cashier/viewer) и привязкой к офису/партнёру - Enforcement принципа least privilege (deny-by-default, точечная выдача прав под задачу) - Конфигурируемые матрицы сегрегации обязанностей (SoD) с блокировкой конфликтных комбинаций - Maker-checker / four-eyes апрув операций с тиерными порогами по сумме - Автопроведение мелких операций и эскалация крупных на второй/третий уровень утверждения - Неизменяемый append-only аудит-лог с hash-chaining (кто/что/когда/старое-новое значение) - WORM-хранение и якорение хэшей лога во внешний источник для доказательства целостности - Ротация апруверов и кассиров для разрушения устойчивых сговоров - Cash-count / till reconciliation смены под dual custody с фиксацией и эскалацией variance - AML transaction monitoring: правила structuring/smurfing, velocity, гео- и контрагент-риск - KYT-скоринг входящих крипто-депозитов (Chainalysis/Elliptic) с флагом illicit-источников - Поведенческие антифрод-алерты (курс хуже стандарта, аномальные отмены, операции вне часов) - MFA/2FA с phishing-resistant факторами (FIDO2/WebAuthn) для привилегированных ролей - Step-up аутентификация в момент апрува операций сверх лимита - Dynamic Data Masking чувствительных полей (телефон, паспорт, адрес кошелька) по роли - Маскирование PII в выгрузках, отчётах и логах + токенизация/шифрование at rest - Конфигурируемые лимиты операций per-role, per-office, per-shift, per-asset - Multisig-управление крипто-кошельками с M-of-N и внешним подписантом - Интеграция с физической безопасностью: dual-control сейф, CCTV, логи доступа в back-office - SIEM/алертинг поверх аудит-лога и аутентификации (отказы доступа, push-bombing, аномалии входа)

Источники: - https://faisalkhan.com/knowledge-center/payments-wiki/r/role-based-access-control-rbac/ - https://www.lightspark.com/glossary/role-based-access-control- - https://pathlock.com/blog/role-based-access-control-rbac/ - https://searchinform.com/articles/risk-management/governance/sod/ - https://www.sikich.com/insight/why-segregation-of-duties-is-a-key-internal-control-and-how-to-implement-it/ - https://www.bpm.com/insights/crypto-compliance-risk-management-strategies/ - https://moneymatters.busey.com/busey-bank-insider-threats-internal-fraud-what-every-business-should-know - https://firstbusiness.bank/resource-center/how-to-prevent-internal-fraud/ - https://www.irs.gov/businesses/small-businesses-self-employed/money-services-business-msb-information-center - https://htb.com/financial-literacy/dual-controls-reduce-risk-corporate-fraud/ - https://www.fdic.gov/risk-management-manual-examination-policies/section-8-1.pdf - https://www.hubifi.com/blog/immutable-audit-log-basics - https://www.hubifi.com/blog/immutable-data-stripe - https://mattermost.com/blog/compliance-by-design-18-tips-to-implement-tamper-proof-audit-logs/ - https://id4d.worldbank.org/guide/tamper-proof-logs - https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/multi-factor-authentication - https://csf.tools/reference/nist-sp-800-53/r5/ac/ac-6/ - https://csf.tools/reference/nist-sp-800-53/r5/ia/ia-2/ia-2-2/ - https://delinea.com/blog/nist-800-53-security-privacy-privileged-access - https://blog.xtrm.com/posts/maker-checker-process - https://en.wikipedia.org/wiki/Maker-checker - https://docs.devolutions.net/rdm/concepts/advanced-concepts/four-eyes-principle/ - https://www.ccn.com/education/crypto/multisig-cold-wallets-crypto-security/ - https://www.csis.org/analysis/bybit-heist-and-future-us-crypto-regulation - https://www.linkedin.com/advice/1/how-do-you-use-dual-control-ensure-security-accuracy - https://en.wikipedia.org/wiki/Bank_vault - https://www.occ.gov/publications-and-resources/publications/comptrollers-handbook/files/cash-accounts/pub-ch-cash-accounts.pdf - https://www.strac.io/blog/pci-dss-pan-masking - https://www.protegrity.com/capabilities/dynamic-data-masking - https://accutivesecurity.com/guide-to-pci-dss-4-data-masking-tokenization/ - https://www.chainalysis.com/glossary/transaction-monitoring/ - https://sumsub.com/blog/aml-transaction-monitoring-rules-scenarios/ - https://www.sanctions.io/blog/anti-money-laundering-aml-transaction-monitoring-rules-and-best-practices - https://robokassa.com/blog/articles/antifrod-chto-eto-takoe/

Интеграции, API, экосистема

Кратко: Детальный отраслевой раздел по направлению «Интеграции, API, экосистема» для back-office крипто-обменника: внутренний/публичный API, фиат on/off-ramp и банковские/карточные/ФОП-каналы, ликвидность-провайдеры и биржи (REST/WebSocket/FIX, RFQ), блокчейн-ноды (TronGrid и альтернативы), chain-analytics/AML (Chainalysis/Elliptic/TRM), Travel Rule, кастоди/оркестрация кошельков, вебхуки и легаси-импорт из Google Sheets/Excel. Покрыты конкретные вендоры, стандарты, цифры, реализация у мелкого обменника vs сети филиалов vs институционального OTC, лучшие практики и риски.

Интеграции, API, экосистема

Модуль «Интеграции» — это нервная система back-office обменника. Он связывает внутренний учёт (сделки, кассы, остатки в USDT) с внешним миром: блокчейном, биржами, банками, карточными процессорами, ФОП-каналами, AML-провайдерами и легаси-источниками вроде Google Sheets. Архитектурно это слой адаптеров поверх единой шины событий, нормализующий разнородные форматы во внутренний канонический контракт транзакции и поддерживающий идемпотентность, ретраи и аудит.

Что делает модуль

Модуль выполняет четыре класса задач: (1) inbound-приём данных — балансы и движения с блокчейна, выписки банков/карт, котировки бирж; (2) outbound-исполнение — отправка ордеров на хедж, вывод/ввод фиата через ramp, sweep крипты в кастоди; (3) enrichment/compliance — скрининг адресов и контрагентов, KYC/KYB, Travel Rule; (4) синхронизация — двусторонняя сверка внутреннего леджера с внешними системами. Каждая интеграция оформляется как изолированный адаптер с собственными грабли-заметками (rate limits, окна выписок, форматы), что критично, потому что у каждого вендора своя специфика (например, Monobank: 31 день/окно, 1 запрос/60 сек).

Блокчейн-ноды и провайдеры

Базовый слой — доступ к ончейн-данным. Для TRON/TRC20 (основной актив USDT-обменника) первичный выбор — TronGrid (официальный, от TRON Foundation), но для продакшена нужна избыточность. Альтернативы: GetBlock, QuickNode (SOC 2 Type II, ISO 27001, SLA 99.99%, 80+ сетей), NOWNodes (99.95% uptime), Chainstack (dedicated-ноды в собственном AWS/GCP/Azure через Hybrid Cloud), dRPC ($6/1M запросов — самый дешёвый at-scale), Bitquery (GraphQL для агрегированных запросов). Ключевой паттерн: не полагаться на один RPC — держать пул эндпоинтов с health-check и failover, использовать gRPC где доступно для скорости, и отдельный путь для подтверждений vs исторических запросов. Для надёжного детектирования депозитов: ждать N подтверждений (TRON быстрый, но reorg возможен), идемпотентный upsert по tx_hash, и обработка reorg (откат неподтверждённых).

Chain-analytics и AML

Скрининг адресов перед зачислением/выводом — обязателен для VASP. Тройка лидеров: - Chainalysis — gold standard для расследований, 1500+ клиентов, KYT с настраиваемыми порогами риска и алертами, сильное cross-chain трейсинг. - Elliptic — покрытие ~99% рынка, 100B+ data points, 150 анализов/сек, до 10 000 транзакций bulk-загрузкой, 99.99% uptime. - TRM Labs — AI-driven, sub-second API, real-time cross-chain, unicorn ($1B). - Бюджетные альтернативы для мелких VASP: AMLBot, Nominis, ChainUp. Паттерн интеграции: synchronous API screening на входящем депозите (risk score → auto-approve / hold / reject) и pre-send проверка получателя на выводе. Скрининг даёт risk-категории (sanctions, darknet, mixer, scam) — важно версионировать ответы и хранить snapshot скоринга для аудита.

Ликвидность, биржи, OTC

Для хеджирования позиции и пополнения остатков обменник интегрируется с биржами и OTC-десками: - Биржи (Binance/Bybit/OKX): REST (/api/v3/, /v5/, /api/v5/) для ордеров и баланса, WebSocket для стаканов/филлов, у части — FIX для институционалов. Унификация через CCXT или CryptoClients.Net (общий интерфейс поверх десятков бирж). - OTC/принципал-ликвидность: B2C2, Cumberland DRW, FalconX, Wintermute, Galaxy, Jane Street. Рабочий процесс — RFQ (Request for Quote): запрос котировки на блок → исполнение по фиксированной цене без проскальзывания. FalconX даёт REST/WebSocket/FIX; агрегаторы (Talos, Liquid Mercury) дают multi-dealer RFQ — подключение к 8+ провайдерам гарантирует реальную конкуренцию котировок.

Фиат on/off-ramp, банки, карты, ФОП

Связь крипты с фиатом — самый зарегулированный слой: - Ramp-агрегаторы/провайдеры: Transak (именованные виртуальные счета для on-ramp, dedicated-адреса для off-ramp), MoonPay (Headless API / widget / SDK), Onramper (агрегатор), Ramp Network, Request Finance (crypto→fiat payout в банки), Lightspark/OpenPayd (один API-вызов с встроенным KYC/KYB/AML/sanctions). - Турция (TRY): Papara (API, e-commerce плагины, payment links; обслуживает крипто-сообщество с 2017), ininal, Paycell; рельсы EFT/FAST. Binance официально интегрировал Papara как fiat-gateway. - Украина (UAH/ФОП): локальные банковские API — Monobank (personal API через X-Token), FinUp (fintech-карты + USDT-кошелёк). Карточный/ФОП-канал часто реализуется через выписки и нормализацию, а не realtime-API. - Кастоди/оркестрация: Fireblocks (MPC-CMP, WaaS, automated treasury sweeps, webhooks на статусы транзакций, движение между кошельками/биржами/контрагентами без раскрытия ключей), BitGo, Coinbase Custody — для сетей с большими остатками.

Вебхуки и событийная модель

Inbound-события (депозит подтверждён, выписка обновлена, котировка) приходят вебхуками. Best practices (универсальны): - Верификация HMAC по RAW-телу (не по распарсенному JSON), с timestamp-префиксом. - Защита от replay: X-Timestamp + отклонение всего старше ~5 мин. - Идемпотентность: ключ = event_id / tx_id; хранить обработанные ID, отклонять дубли (webhook может прийти дважды). - Async-обработка: мгновенный 200 OK → enqueue → обработка воркером; хендлер делает только validate+enqueue. - Ротация секретов: два активных секрета внахлёст (X-Signature-v1/v2).

Легаси-импорт из Google Sheets/Excel

Исторически учёт касс ведётся в Google Sheets/Excel — это легаси-источник, который нельзя выключить мгновенно. Паттерн: Google Sheets API v4 (JSON, не deprecated v3), парсинг именованных блоков (DEPOSIT-блоки, лист «Возврат», сводная), нормализация в канонический контракт сделки, идемпотентный upsert по натуральному ключу (дата+касса+сумма+контрагент) для повторного импорта без дублей, и сверка контрольных сумм с внутренним леджером до цента. ETL-инструменты (Airbyte, Skyvia, Stitch, CData) подходят для warehouse-выгрузки, но для бизнес-логики обменника обычно пишут собственный адаптер.

Как реализуют разные операторы

• Мелкий обменник: один RPC (TronGrid free), ручной/полуавтоматический импорт из Sheets, AML — разовый скрининг через дешёвый сервис, хедж — вручную на одной бирже через CCXT. Риск: single point of failure, отсутствие Travel Rule.
• Сеть филиалов (этот кейс): пул RPC с failover, нормализующий слой адаптеров по офисам/каналам (Monobank, FinUp, Papara, кошельки), авто-сверка ончейн↔сделки со скорингом, версионирование. AML-скрининг на входе. Учёт в USDT как единой валюте.
• Институциональный OTC-деск: Fireblocks-кастоди, multi-dealer RFQ через Talos, FIX-коннект к B2C2/Cumberland, полный Travel Rule (IVMS101 + TRP/Notabene/Sumsub), KYT в реальном времени, SOC2-провайдеры нод.

Регуляторика и стандарты

• FATF Travel Rule (R.16): VASP обязан собирать/верифицировать данные отправителя и получателя и передавать контрагенту. Канонический формат payload — IVMS101; транспортные протоколы — TRP (Travel Address решает Sunrise-проблему), Sygna (APAC), OpenVASP. Вендоры: Notabene (approve/reject до отправки on-chain), Sumsub (Travel Rule как add-on к KYC), TRM/Chainalysis-интероп.
• Идентификация: KYC/KYB через Sumsub и аналоги.

Типичные ошибки и риски

• Зависимость от единственного RPC/вебхук-провайдера без failover.
• Отсутствие идемпотентности → двойные зачисления при retry вебхука.
• Верификация подписи по распарсенному (а не raw) телу → обход подписи.
• Игнор reorg/недостаточно подтверждений → фантомные депозиты.
• Хранение API-ключей в коде вместо secret-manager; отсутствие IP-whitelist.
• Несверяемый легаси-импорт из Sheets (дубли, расхождение копеек).
• Запоздалый Travel Rule / AML → блокировки банковских и биржевых счетов (de-risking).
• Отсутствие версионирования ответов AML — невозможно реконструировать решение для аудита.

Ключевые функции: - Пул блокчейн-RPC с health-check и failover (TronGrid + QuickNode/GetBlock/Chainstack) - Детектирование депозитов с ожиданием N подтверждений и обработкой reorg - Идемпотентный upsert ончейн-транзакций по tx_hash - AML-скрининг адресов через Chainalysis/Elliptic/TRM с risk-score gating (approve/hold/reject) - Pre-send проверка получателя на выводе - RFQ-исполнение блок-сделок через OTC-десков (B2C2/FalconX/Cumberland) - Хедж-ордера на биржах через REST/WebSocket/FIX (унификация CCXT) - Фиат on/off-ramp через Transak/MoonPay/Onramper (виртуальные счета, dedicated-адреса) - Локальные фиат-каналы: Papara API (TRY), Monobank X-Token API, FinUp (UAH/ФОП) - MPC-кастоди и automated treasury sweeps через Fireblocks с webhook-нотификациями - Приём вебхуков: HMAC по raw-телу + timestamp-replay-защита + async enqueue - Идемпотентность вебхуков по event_id с хранением обработанных ID - Ротация webhook-секретов с overlap двух активных версий - Импорт легаси Google Sheets через API v4 с парсингом DEPOSIT/Возврат/сводных блоков - Идемпотентный upsert импорта по натуральному ключу и сверка контрольных сумм до цента - Travel Rule: формирование IVMS101-payload и передача через TRP/Notabene/Sumsub - KYC/KYB-верификация контрагентов (Sumsub) - Двусторонняя сверка внутреннего USDT-леджера с биржевыми/банковскими балансами - Нормализация разнородных источников в канонический контракт транзакции - Версионирование и snapshot ответов внешних провайдеров (AML, котировки) для аудита

Источники: - https://transak.com/ - https://onramper.com/ - https://www.request.finance/tech - https://www.lightspark.com/products/ramps - https://www.openpayd.com/on-off-ramp/ - https://www.moonpay.com/business/ramps - https://getblock.io/blog/top-tron-api-providers/ - https://chainstack.com/best-tron-rpc-providers-2026/ - https://drpc.org/blog/best-tron-rpc-providers/ - https://www.alchemy.com/overviews/blockchain-node-providers - https://bitquery.io/blog/top-tron-apis - https://cryptotracelabs.com/blog/chainalysis-vs-elliptic-vs-trm-labs-which-platform-should-investigators-choose/ - https://finconduit.com/resources/blockchain-analytics-providers-compared - https://blog.amlbot.com/chainalysis-alternatives-crypto-aml/ - https://blog.tokenmetrics.com/p/best-crypto-otc-desks-for-large-block-trades-2026 - https://www.b2c2.com/newspost/b2c2-launches-first-electronic-otc-options-trading-product-for-crypto-markets - https://www.liquidmercury.com/resources/crypto-otc-desk-software - https://www.talos.com/insights/talos-expands-rfq-platform-with-falconx-electronic-otc-options-integration - https://www.falconx.io/services/trading - https://medium.com/@sohail_saifii/handling-payment-webhooks-reliably-idempotency-retries-validation-69b762720bf5 - https://nxtbanking.com/webhook-security-hmac-signature-verification/ - https://www.cobo.com/post/crypto-payment-api - https://www.okx.com/docs-v5/en/ - https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams - https://bybit-exchange.github.io/docs/v5/websocket/public/orderbook - https://github.com/ccxt/ccxt/wiki/manual - https://nowpayments.io/blog/payment-gateway-turkey - https://www.transfi.com/blog/turkeys-payment-rails-how-they-work---eft-fast-digital-wallet-growth - https://www.binance.com/en/blog/all/binance-announces-fiattocrypto-gateway-for-turkey-in-partnership-with-local-partner-papara-403466093493387264 - https://www.transfi.com/blog/best-crypto-and-fiat-payment-gateway-in-ukraine---accept-uah-and-crypto-payments-safely - https://developers.google.com/workspace/sheets/api/guides/migration - https://skyvia.com/connectors/google-sheets - https://sumsub.com/blog/what-is-the-fatf-travel-rule/ - https://notabene.id/crypto-travel-rule-101/what-is-the-crypto-travel-rule - https://finconduit.com/resources/travel-rule-architecture-build-2026 - https://developers.fireblocks.com/docs/wallet-as-a-service - https://www.fireblocks.com/report/what-is-mpc

Ландшафт продуктов: коммерческие CRM/white-label и как работают игроки

Кратко: Рынок ПО для обменников и OTC расслоён по трём ценовым/функциональным тиерам: дешёвые «exchanger-скрипты» для онлайн-обменников ($349/мес аренда или ~$9 990 лицензия — Premium Exchanger, BoxExchanger), white-label CRM/back-office среднего звена ($60–100K+, MiCA-ready — Crassula, HollaEx, B2Core/B2Broker, AlphaPoint) и институциональные OTC-стэки с RFQ/агрегацией ликвидности (AlphaPoint, Talos, Finery Markets, Liquid Mercury). Кастомная сборка стоит $5M+ и 18–36 мес против 6–14 недель на white-label, поэтому build оправдан только если дифференциатор лежит в самом движке. Для сети наличных офисов готового «коробочного» продукта почти нет — закрывают либо франшизной CRM (MultiKassa), либо самописным учётом, что и подтверждает выбор build для данного бизнеса.

Ландшафт продуктов: коммерческие CRM/white-label и как работают игроки

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

Сегмент 1. «Exchanger-скрипты» (онлайн-обменники e-currency)

Это самый зрелый и дешёвый слой — скрипты для автоматических онлайн-обменников, ориентированных на агрегаторы-мониторинги (BestChange, Obmennik.ws, Obmify).

• Premium Exchanger — аренда $349/мес или вечная лицензия $9 990 (с привязкой к домену, рассрочка на 6 мес). 4 роли (Administrator/Manager/Operator/User), генерация XML-фида курсов для мониторингов, автовыплаты через Binance, Rapira, ABCEX, Heleket, Payeer, Volet/Advcash, WebMoney; merchant-модули; партнёрка с тирами; плавающие курсы от суммы и резервов; дневные/месячные лимиты; блэклисты.
• BoxExchanger — аналог с акцентом на AML: интеграции CrystalBlockchain, AMLBot, MistTrack, GetBlock; KYC через Kycaid/Sumsub/AMLBot; парсинг курсов с Binance P2P, WhiteBIT, Currencyapi; авто-обновление резервов по завершённым операциям; экспорт заявок в .xlsx; статистика по направлениям/прибыли/визитам.

Модель данных: Order (заявка), Direction (направление обмена), Reserve, Rate, PaymentSystem, User, Referral. Рабочий процесс: клиент создаёт заявку на сайте → автоприём оплаты/мерчант → AML-скоринг → авто- или ручная выплата → обновление резерва. Сильная сторона — полная автоматизация и интеграция с мониторингами; слабая — это «фронт интернет-витрины», в них нет мультифилиального кассового учёта, смен, наличных, инвентаризации офисов.

Сегмент 2. White-label CRM / back-office (средний бизнес, MiCA-ready)

Здесь живут «коробочные биржи под ключ» с матчинг-движком, кошельками, KYC/KYB и админкой. Ключевые вендоры:

• B2Broker / B2Core (Trader's Room) — B2B SaaS/white-label back-office для Forex/Crypto-брокера, крипто-биржи, кошелька и OTC-брокериджа. CRM управляет всем жизненным циклом клиента: KYC, кошельки, платежи, IB/партнёрские модули, институциональная ликвидность (Prime-of-Prime), коннекторы к MT4/MT5, cTrader, B2Trader, DXtrade.
• Crassula — MiCA-ready: матчинг-движок, order book, мультивалютные кошельки, выпуск IBAN/карт, KYC/KYB-оркестрация, Travel Rule, custody-партнёры, управление маркапами и комиссиями в back office; обслуживает 150+ компаний (challenger-банки, крипто-банки).
• HollaEx — award-winning, частично open-source, self-hosted и cloud, со встроенными OTC-broker фичами и order book.
• AlphaPoint, Shift Markets, WL Global Solutions, Suffescom, Bitdeal — похожий стек с упором на security, масштабируемость, токенизацию.

Ценообразование: clone-скрипты $8–14K; реалистичный «пол» для compliance-ready white-label — $60–100K + SaaS-роялти/revenue-share; полноценная кастомизация $50–500K. Покупатель — региональный брокер, необанк, добавляющий крипту, или MiCA-CASP бренд, которому нужна биржа/витрина, но не уникальный движок.

Сегмент 3. Институциональные OTC-десковые стэки

Самый дорогой и узкий слой — инфраструктура для голосовых/электронных OTC-десков, торгующих крупными блоками.

• AlphaPoint OTC — negotiated и RFQ-workflow, конфигурируемая логика прайсинга и аппрувов, разделение прав execution/operations, real-time exposure по контрагентам, лимиты, settlement-координация, on-chain/off-chain баланс-трекинг, аудит-логи, институциональная отчётность; коннект к 100+ биржам.
• Talos — агрегация ликвидности из 50–60+ венью в единый order book для OTC-десков; white-label.
• Finery Markets, Liquid Mercury, FinchTrade (Swiss crypto-fiat OTC, settlement ~30 мин в стейблах), Keyrock, Inqud.

Ядро — RFQ-движок: время между запросом клиента и показом конкурирующих котировок измеряется миллисекундами; streaming-котировки дают лучше цену, чем request-response. Подключение к 8+ тир-1 провайдерам (B2C2, Cumberland DRW, Jane Street, Wintermute) даёт реальную multi-dealer конкуренцию. Модель данных: Client (с риск-параметрами), LP-connection/pricing-stream, Trade, Position-ledger/P&L, Settlement-instruction, Custodian-mapping. Pre-trade контроли (кредитные/позиционные лимиты, аппрув контрагента, sanctions-скрининг) и post-trade (real-time P&L, статус сеттлмента) работают автоматически, без ручного вмешательства. Маркап настраивается per-client / per-asset / per-volume-tier.

Как это реализуют разные операторы

• Мелкий обменник — берёт скрипт ($349/мес) или франшизу. Часто весь «учёт» — это админка скрипта + Google-таблицы. Кассового модуля нет, наличные считаются вручную.
• Сеть филиалов (наличные) — здесь зияющая дыра в рынке: коробочных продуктов под мультиофисный кассовый учёт (смены, инкассация, остатки по кассам, межофисные переводы, сверка налички с он-чейн-кошельками) практически нет. Закрывают двумя путями: (1) франшизная CRM — например MultiKassa (офисы в РФ/ОАЭ, паушальный взнос + роялти, собственная CRM «под обменный бизнес»: клиенты, заявки, курсы, движение средств, аналитика по направлениям, поток заявок); (2) самописный учёт (как в данном проекте). Именно отсутствие готового SKU объясняет, почему сеть наличных офисов строит свой back-office.
• Институциональный OTC-деск — покупает Сегмент-3 стэк или строит сам, если латентность/клиринг — конкурентное преимущество.

Build vs Buy: цифры

Кастомная сборка биржи — $5M+ и 18–36 месяцев против 6–14 недель на white-label. Правило индустрии: build только если дифференциатор в движке (ультра-низкая латентность деривативов, новый AMM, уникальная клиринговая модель); во всех прочих случаях white-label быстрее, дешевле, безопаснее. Матчинг-движок уровня DXmatch — sub-100µs, до 100K ордеров/сек — экономически невозоспроизводим самостоятельно. Регуляторика: MiCA применяется в ЕС с 30.12.2024, CASP-авторизация даёт passporting, own-funds €50–150K, сегрегация клиентских активов, proof-of-reserves; в Турции — KVMKS (центральный реестр крипто-активов, сверка балансов между платформами и кастодианами).

Лучшие практики и типичные ошибки

• Best practice: разделять execution- и operational-права (RBAC); автоматизировать резервы/сверку; per-client/asset/tier маркапы; интеграция AML до выплаты; аудит-лог всех действий десков.
• Типичные ошибки: (1) покупать exchanger-скрипт под наличную сеть — он не покрывает кассы/смены; (2) недооценить compliance-floor ($60–100K) и регуляторику (MiCA/Travel Rule); (3) request-response котировки вместо streaming в OTC; (4) ручной кассовый учёт без сверки с он-чейн-балансами → расхождения; (5) vendor lock-in во франшизной CRM (роялти + чужой контроль над потоком заявок), что снижает маржу — реальные отзывы по MultiKassa указывают на спорную окупаемость.

Ключевые функции: - RFQ/quoting-движок: агрегация конкурирующих котировок от 8+ LP за миллисекунды, streaming vs request-response, countdown-таймеры валидности котировки - Liquidity aggregation: подключение к 50–100+ венью/биржам и тир-1 маркет-мейкерам в единый order book - Парсинг и управление курсами: Binance P2P, WhiteBIT, ECB/центробанки + плавающие курсы от суммы и резервов - Reserve management: автообновление резервов валют по завершённым операциям, ручные коррекции - Per-client / per-asset / per-volume-tier маркапы и управление комиссиями в back office - KYC/KYB-оркестрация: Sumsub, Kycaid, AMLBot + decision-making система верификации - AML/транзакционный скрининг: CrystalBlockchain, MistTrack, AMLBot, sanctions-screening до выплаты - Travel Rule compliance и proof-of-reserves (MiCA/CASP) - Мультивалютные кошельки + выпуск IBAN/карт, on-chain/off-chain balance tracking - Pre-trade risk controls: кредитные/позиционные лимиты, аппрув контрагента, exposure по партнёрам - Post-trade: real-time P&L, position ledger, статус сеттлмента, netting - Settlement & treasury: генерация settlement-instructions, custodian-routing, интеграция с reconciliation - RBAC: разделение прав execution и operations, роли Admin/Manager/Operator/User - Audit-логирование всех действий десков и админки - Авто/ручные выплаты и merchant-модули (Binance, Payeer, Volet, WebMoney, стейблы) - Партнёрская/IB-программа с настраиваемыми тирами комиссий и ручными выплатами - Отчётность: статистика по направлениям/прибыли/визитам, экспорт заявок в .xlsx, институциональная отчётность - XML-фид курсов для мониторингов (BestChange) и витрина заявок - Кассовый/мультифилиальный учёт (смены, остатки по кассам, инкассация) — слабое место рынка, закрывается франшизной или самописной CRM - Сверка наличных и фиатных остатков с он-чейн-балансами кошельков

Источники: - https://b2broker.com/news/best-white-label-crypto-exchange-software/ - https://crassula.io/features/currency-exchange/ - https://crassula.io/guides/crypto-exchange-software/ - https://www.liquidmercury.com/resources/crypto-otc-desk-software - https://alphapoint.com/product/otc-software/ - https://www.boxexchanger.net/script/ - https://premiumexchanger.com/en/ - https://b2broker.com/products/b2core-traders-room/ - https://b2broker.com/news/how-much-does-it-cost-to-start-a-crypto-exchange/ - https://finerymarkets.com/otc-desks.html - https://www.talos.com/clients/otc-desks - https://finchtrade.com/ - https://www.bitget.com/academy/best-crypto-otc-desks-institutional-trading-platforms-reviewed - https://franchise.multikassa.com/ - https://multikassa.com/en/articles/kak-otkryt-kriptoobmennyi-punkt-po-fransize-multikassa - https://www.wlglobal.solutions/blog/cryptocurrency-exchange-development-cost/ - https://www.hollaex.com/white-label-crypto-exchange - https://www.mkk.com.tr/en/investor-services/crypto-asset-central-registry-system-kvmks

Регуляторика по ключевым юрисдикциям

Кратко: Regulation of crypto exchangers and OTC desks tightened sharply in 2024-2026: the EU's MiCA became fully applicable (final CASP deadline ~1 July 2026), Turkey introduced a full CASP licensing regime (SPK Communiqués III-35/B.1 & B.2, March 2025) plus aggressive MASAK AML limits (48/72h withdrawal holds, $3,000/day stablecoin cap), Ukraine is moving from a grey zone toward a VASP regime and 18%+5% crypto tax from 2026, while the US (FinCEN MSB/BSA, GENIUS Act) and Canada (FINTRAC) keep mature money-transmitter regimes anchored by the FATF Travel Rule (Recommendation 16, revised June 2025). The cross-cutting consequence is that any back-office CRM must natively support KYC/KYB, tiered transaction monitoring, Travel Rule data exchange, sanctions/PEP screening, configurable jurisdiction limits, mandatory regulatory reports (SAR/STR/CTR/LVCTR), and 5-10 year tamper-evident record retention.

Регуляторика по ключевым юрисдикциям

Регулирование обменников наличной/безналичной крипты и OTC-десков в 2024-2026 перешло из «серой зоны» в режим жёсткого лицензирования. Ниже — разбор по юрисдикциям, общий слой стандартов (FATF), и прямое влияние на функционал CRM/back-office.

1. Турция (CASP-режим SPK + AML-меры MASAK)

Самый релевантный для антальянско-аланьинской сети контур. 13 марта 2025 г. Совет по рынкам капитала (SPK/CMB) опубликовал в Resmî Gazete два коммюнике — III-35/B.1 (учреждение и деятельность) и III-35/B.2 (операционные принципы, корпуправление, достаточность капитала).

• Двухступенчатое лицензирование: сначала establishment licence, затем operating licence. CASP должен быть АО (anonim şirket) с полностью оплаченным капиталом.
• Капитал: платформа — мин. 100 млн TRY, чистый кастодиан — 50 млн TRY.
• Переходный период: действующие игроки обязаны подать заявку; кто не подал/получил отказ — считается работающим нелегально.
• AML — MASAK Genel Tebliği No. 29 (Resmî Gazete № 32940 от 28.06.2025), вступил в силу немедленно и крайне практичен:
• Холд на вывод: 48 часов на обычный вывод, 72 часа на первый вывод после покупки/свопа/депозита.
• Лимиты стейблкоинов (USDT/USDC/etc): $3 000/день и $50 000/месяц; для CASP, полностью реализовавших Travel Rule (полные данные отправителя/получателя), лимиты удваиваются.
• Идентификация обязательна на транзакциях свыше 15 000 TRY (~$425).
• Полномочия замораживать счета при подозрении.

Это напрямую бьёт по бизнес-модели «быстрый наличный обмен на USDT»: софт обязан уметь enforce'ить холды и лимиты per-customer/per-asset.

2. EU / MiCA (+ TFR)

MiCA (Regulation (EU) 2023/1114) — единый паспорт CASP на 27 стран. Stablecoin-правила (ART/EMT) — с 30.06.2024; основной CASP-блок — с 30.12.2024.

• Переходные периоды разнятся по странам: от 6 мес (Нидерланды, Польша, Литва, Латвия, Венгрия, Словения, Финляндия — уже истёк) до 12-18 мес (Германия/Испания до 30.12.2025, Франция/Мальта до 30.06.2026). Финальный дедлайн по всему ЕС ~1 июля 2026 — без MiCA-лицензии обслуживать клиентов ЕС нельзя.
• Минимальный капитал по типу услуг: €50k (консультирование/приём-передача), €125k (кастоди, обмен, исполнение), €150k (торговая платформа).
• Travel Funds Regulation (TFR, Reg. 2023/1113): нулевой порог — любой крипто-перевод сопровождается полными данными отправителя и получателя независимо от суммы (самая жёсткая имплементация в мире).
• Требования: governance, защита клиентских активов (сегрегация), IT-безопасность, white-paper при эмиссии, рыночные злоупотребления (MAR-аналог).

3. СНГ / Украина (ФОП и крипто)

Украинский фиат-ФОП-канал работает в переходной фазе: - Криптоактивы не запрещены, но специального действующего режима пока нет (серая зона на середину 2025). - Законопроект № 10225-д (внесён 24.04.2025, принят в первом чтении в сентябре 2025) выравнивает правила с ЕС: вводит режим VASP с регистрацией, KYC/AML, ежегодной отчётностью; классифицирует активы на asset-backed / e-money / прочие. - Налоги (поправки в НКУ, с 01.01.2026): 18% НДФЛ + 5% военный сбор на прибыль при конвертации крипты в фиат в первый год; crypto-to-crypto и мелкие операции — освобождены; майнинг/стейкинг/airdrop — доход при конвертации в фиат. - Практическое следствие для ФОП-канала: нужна фиксация момента «крипта→фиат» и расчёт налоговой базы — CRM должна метить такие конверсии.

4. США (FinCEN MSB / BSA) и Канада (FINTRAC)

Зрелые money-transmitter режимы, релевантны для онлайн-OTC с американскими/канадскими контрагентами.

США: - Конвертируемая виртуальная валюта = money transmission → регистрация MSB в FinCEN в течение 180 дней (31 CFR 1022.380), перерегистрация раз в 2 года, ведение agent list. - Обязательства BSA: письменная AML-программа, KYC, мониторинг, SAR (подозрительные) и CTR (наличные ≥$10k). - Travel Rule в США: порог $3 000 (предложение снизить до $250 не финализировано). - GENIUS Act (июль 2025): платёжные стейблкоины под BSA — CDD, мониторинг, SAR, OFAC-скрининг. - Штрафы: до ~$219k/день за умышленное нарушение BSA.

Канада: - С 01.06.2020 dealing in virtual currency = MSB → регистрация FINTRAC (одна на все провинции; Квебек требует доп. AMF-лицензию). - Travel Rule (PCMLTFA) с 01.06.2021, порог CAD 1 000. - LVCTR (Large Virtual Currency Transaction Report) при получении ≥ CAD 10 000; STR, полная AML-программа.

5. Общий слой — FATF Recommendation 16

Глобальный базис, на котором стоят все национальные режимы. Пересмотрена в июне 2025: цели Travel Rule расширены за пределы ML/TF — добавлены fraud prevention и proliferation financing; введена Confirmation of Payee для трансграничных переводов; интеграция с ISO 20022. Рекомендованный порог — USD/EUR 1 000. По опросу FATF 2025 — 85 из 117 юрисдикций приняли Travel Rule-законодательство.

6. Хранение данных и отчётность

• Хранение KYC/AML/транзакционных записей — минимум 5 лет (часто 5-10 лет после окончания отношений), в крипте включая on-chain данные, адреса кошельков и выводы blockchain-аналитики.
• Отчётные артефакты: SAR/STR, CTR/LVCTR, годовые отчёты VASP, Travel Rule payloads.

7. Как реализуют разные операторы

• Мелкий обменник (1-2 офиса): часто покупает SaaS-стек (Sumsub KYC+Travel Rule, AMLBot/Chainalysis для скрининга адресов), enforce-лимиты вручную/полу-автоматом. Главный риск — игнорирование лицензии и порогов идентификации.
• Сеть филиалов (этот кейс): нужен единый back-office с per-branch ролями, агрегированной отчётностью, конфигурируемыми per-jurisdiction лимитами (TR-холды vs UA-налоги vs EU нулевой порог TFR), централизованным AML-офицером.
• Институциональный OTC-деск: KYB/EDD контрагентов, settlement через банки, source-of-funds, расширенный мониторинг mixers/privacy-tools, выделенная compliance-команда, интеграция Elliptic/TRM Labs в alert→decision pipeline.

8. RegTech-вендоры (стек комплаенса)

Рынок крипто-комплаенса: ~$3.5 млрд (2025) → $9 млрд (2032), CAGR ~14%. Ключевые: Chainalysis (KYT-мониторинг, address screening), Elliptic (cross-chain risk, Lens), TRM Labs (wallet/entity risk scoring), Sumsub (KYC+AML+Travel Rule в одной интеграции), Notabene/21 Analytics (Travel Rule routing), Flagright/AMLBot (мониторинг).

9. Тренды 2025-2026

1. Конец «серых зон» — MiCA, турецкий CASP, украинский VASP-режим запускаются почти синхронно.
2. Нулевой/низкий порог Travel Rule становится нормой (EU=0, FATF revised, Confirmation of Payee).
3. Стейблкоины под прицелом — лимиты в Турции, GENIUS Act в США.
4. ISO 20022 как messaging-стандарт для interoperability Travel Rule.
5. Хост-страновой риск-арбитраж сужается: операторы вынуждены лицензироваться там, где обслуживают клиента.

10. Типичные ошибки и риски

• Работа без лицензии в переходный период (Турция/EU считают это нелегальной деятельностью).
• Невыполнение порогов идентификации (TR 15k TRY, CTR $10k, LVCTR CAD 10k).
• Отсутствие Travel Rule-обмена → потеря удвоенных лимитов в Турции, breach в EU.
• Недостаточное хранение записей (<5 лет) и неверсионируемые данные.
• Отсутствие сегрегации клиентских активов.
• Ручной enforcement лимитов/холдов вместо системного.

Влияние на функционал CRM

Софт обязан уметь: tiered KYC/KYB с порогами идентификации; per-jurisdiction конфиг лимитов и холдов (TR 48/72h, $3k/день стейбл); Travel Rule data-exchange (originator/beneficiary, CoP); sanctions/PEP/adverse-media скрининг; on-chain address risk scoring; транзакционный мониторинг с алертами и SAR/STR-воркфлоу; генерацию CTR/LVCTR/годовых VASP-отчётов; расчёт налоговой базы при крипто→фиат (UA 18%+5%); tamper-evident аудит-лог и retention 5-10 лет; ролевую сегрегацию по филиалам и роль AML-офицера.

Ключевые функции: - Tiered KYC/KYB с порогами идентификации (TR 15k TRY, FATF 1000 USD/EUR) и хранением документов - Per-jurisdiction конфигурируемые лимиты и enforce-холды на вывод (TR: 48/72h, $3k/день и $50k/мес для стейблкоинов) - Travel Rule data-exchange: сбор/передача данных отправителя и получателя + Confirmation of Payee для cross-border - Поддержка нулевого порога TFR для клиентов ЕС (полные данные при любой сумме) - Sanctions / PEP / adverse-media скрининг сторон сделки в реальном времени - On-chain address risk scoring и blockchain-аналитика (интеграция Chainalysis/Elliptic/TRM) - Транзакционный мониторинг с rule-based и поведенческими алертами (mixers, privacy-tools, structuring) - Воркфлоу формирования и подачи SAR / STR (подозрительные операции) - Автогенерация CTR (US ≥$10k) и LVCTR (Canada ≥CAD 10k) по наличным/крипто-порогам - Реестр VASP/CASP-отчётности: годовые отчёты, agent list, перерегистрация MSB раз в 2 года - Расчёт налоговой базы на конверсии крипта→фиат (UA 18% НДФЛ + 5% военный сбор с 2026) - Сегрегация и учёт клиентских активов отдельно от операционных (MiCA safeguarding) - Tamper-evident аудит-лог и сквозное версионирование всех записей - Retention-политика: автоматическое хранение KYC/транзакций/on-chain данных 5-10 лет - Ролевая модель RBAC по филиалам + выделенная роль AML-compliance-офицера - Учёт source-of-funds / EDD для крупных и институциональных OTC-контрагентов (KYB) - Поддержка ISO 20022-messaging для interoperability Travel Rule между VASP - Дашборд лицензионного статуса и дедлайнов по юрисдикциям (MiCA ~01.07.2026, переходные периоды) - Сегрегированный учёт стейблкоин-операций под отдельные лимиты и отчётность (GENIUS Act, MASAK No.29)

Источники: - https://sumsub.com/blog/crypto-regulations-turkey/ - https://cms-lawnow.com/en/ealerts/2025/03/tuerkiye-introduces-new-crypto-asset-regulations-a-landmark-development-in-digital-finance - https://cointelegraph.com/news/turkey-regulator-cmb-two-docs-crypto-regulation - https://evrenozmen.com.tr/new-crypto-rules-in-turkey-48-hour-transfer-hold-and-daily-limits - https://www.mondaq.com/turkey/fin-tech/1652104/masak-communiqu%C3%A9-introducing-tightened-measures-for-crypto-asset-service-providers-has-entered-into-force - https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica - https://sumsub.com/blog/crypto-regulations-in-the-european-union-markets-in-crypto-assets-mica/ - https://www.deepidv.com/media/news/mica-final-deadline-60-days-crypto-authorization-eu - https://www.lw.com/en/markets-in-crypto-assets-regulation-tracker/mica-requirements-casps - https://www.globallegalinsights.com/practice-areas/blockchain-cryptocurrency-laws-and-regulations/ukraine/ - https://itukraine.org.ua/en/new-rules-for-cryptocurrency-how-virtual-assets-will-be-taxed-in-ukraine/ - https://coingeek.com/ukraine-weighs-new-bill-aligning-its-crypto-laws-with-eu/ - https://www.fincen.gov/fact-sheet-msb-registration-rule - https://notabene.id/world/usa - https://hodder.law/fincen-crypto-guidance/ - https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/travel-acheminement/1-eng - https://www.21analytics.co/travel-rule-regulations/canada-travel-rule-regulation/ - https://sumsub.com/blog/what-is-the-fatf-travel-rule/ - https://www.fatf-gafi.org/content/dam/fatf-gafi/recommendations/Best-Practices-Travel-Rule-Supervision.pdf - https://hacken.io/discover/crypto-travel-rule/ - https://www.chainalysis.com/glossary/travel-rule/ - https://coincub.com/vasp-kyc-2025/ - https://kyc-chain.com/guide/kyc-aml-compliance-guide-for-otc-trading-desks/ - https://www.grantthornton.com/insights/articles/banking/2026/crypto-compliance-in-2026 - https://www.kingsresearch.com/report/crypto-compliance-solutions-market-3043