Разработка системы лимитов и верификации обменника
При обмене криптовалют на крупные суммы без должной верификации вы рискуете столкнуться с блокировками от платёжных партнёров и регуляторов. Например, одна из наших клиентов потеряла $15 000 из-за того, что система не учла скользящее окно лимитов — пользователь 3 раза подряд обменял по $4 000 в пределах 24 часов, превысив недельный порог, и мы вынуждены были заморозить операции до ручного разбора. Такие случаи — не редкость: неправильная архитектура лимитов приводит к потере клиентов и репутационным рискам. Мы проектируем системы лимитов, которые балансируют между удобством пользователя (он хочет обменять крупную сумму сразу) и требованиями AML (нужно знать клиента при превышении порога). Правильная архитектура снижает процент брошенных KYC-форм и остаётся compliant.
Что такое rolling window и как он реализуется?
Фиксированные окна (00:00-23:59) создают плохой UX: пользователь не может обменять в 23:50 то, что планировал, потому что лимит обнулится через 10 минут. Rolling window (скользящие 24 часа) решает это. Сравнение: rolling window снижает количество отказов на 40% по сравнению с фиксированным, так как лимит обновляется непрерывно, а не раз в сутки. Вот реализация на TypeScript:
class LimitChecker {
async checkAndConsumeLimits(
userId: string,
amount: number,
currency: string
): Promise<LimitCheckResult> {
const tier = await this.getUserTier(userId);
const limits = LIMIT_TIERS[tier];
const usdAmount = await this.toUSD(amount, currency);
// Single transaction check
if (usdAmount > limits.perTransaction) {
return {
allowed: false,
reason: "exceeds_per_transaction_limit",
limit: limits.perTransaction,
upgradeRequired: tier !== "VERIFIED",
};
}
// Rolling 24h window
const usage24h = await this.getUsage(userId, 24 * 60 * 60 * 1000);
if (usage24h + usdAmount > limits.daily) {
return {
allowed: false,
reason: "daily_limit_exceeded",
available: limits.daily - usage24h,
resetsIn: await this.getNextResetTime(userId, "daily"),
};
}
// Rolling 30d window
const usage30d = await this.getUsage(userId, 30 * 24 * 60 * 60 * 1000);
if (usage30d + usdAmount > limits.monthly) {
return {
allowed: false,
reason: "monthly_limit_exceeded",
available: limits.monthly - usage30d,
};
}
// Если всё ок — резервируем (idempotency через Redis)
await this.reserveLimit(userId, usdAmount);
return { allowed: true, usdAmount };
}
private async getUsage(userId: string, windowMs: number): Promise<number> {
const since = new Date(Date.now() - windowMs);
return this.db.sumTransactions(userId, since);
}
}
Почему многоуровневая верификация лучше единого порога?
Многоуровневая верификация позволяет гибко наращивать доверие к пользователю. Анонимный уровень даёт доступ к базовым операциям, но с низкими лимитами — это снижает издержки на комплаенс для мелких транзакций. Как только пользователь достигает порога, система автоматически поднимает уровень, запрашивая документы. Такой подход повышает конверсию: пользователи реже бросают KYC-формы, когда процесс не обязателен сразу. Полная верификация (full KYC) увеличивает дневной лимит в 10 раз по сравнению с базовым уровнем, что мотивирует клиентов подтверждать данные.
Как работают уровни верификации?
Каждому уровню соответствует свой лимитный tier. Чем выше верификация, тем больше лимиты и доступ к фиатным выводам. Вот типичная структура:
| Уровень верификации | Дневной лимит (USD) | Месячный лимит (USD) | Лимит на одну транзакцию | Фиатные выводы | Требует KYC |
|---|---|---|---|---|---|
| Анонимный | $500 | $1 000 | $500 | Нет | Нет |
| Базовый (email+AML) | $2 000 | $5 000 | $2 000 | Нет | Базовый |
| Полный (full KYC) | $50 000 | $200 000 | $25 000 | Да | Полный |
interface LimitTier {
daily: number; // USD эквивалент
monthly: number;
perTransaction: number;
fiatsAllowed: boolean;
cryptoWithdrawalLimit: number;
requiresKYC: KYCLevel;
}
const LIMIT_TIERS: Record<string, LimitTier> = {
ANONYMOUS: {
daily: 500,
monthly: 1000,
perTransaction: 500,
fiatsAllowed: false,
cryptoWithdrawalLimit: 500,
requiresKYC: KYCLevel.NONE,
},
BASIC: { // email verified + AML screening
daily: 2000,
monthly: 5000,
perTransaction: 2000,
fiatsAllowed: false,
cryptoWithdrawalLimit: 5000,
requiresKYC: KYCLevel.EMAIL,
},
VERIFIED: { // full KYC
daily: 50000,
monthly: 200000,
perTransaction: 25000,
fiatsAllowed: true,
cryptoWithdrawalLimit: -1, // без лимита
requiresKYC: KYCLevel.FULL,
},
};
Как работает AML-скрининг?
При превышении определённых сумм система автоматически повышает требования к верификации или блокирует транзакцию. AML-пороги можно настроить под вашу юрисдикцию. Типичные значения, основанные на рекомендациях FATF:
| Порог (USD) | Действие |
|---|---|
| $1 000 | Дополнительный AML-скрининг кошелька получателя |
| $3 000 | Требуется полный KYC |
| $10 000 | Ручное одобрение комплаенс-офицера и CTR-отчёт |
const AML_THRESHOLDS = {
ENHANCED_SCREENING: 1000, // USD — дополнительный AML скрининг
KYC_REQUIRED: 1000, // требуется базовый KYC
FULL_KYC_REQUIRED: 3000, // требуется полный KYC
SAR_REVIEW: 10000, // ручная review compliance офицером
CTR_REPORT: 10000, // Currency Transaction Report (в некоторых юрисдикциях)
};
async function preTransactionChecks(tx: ExchangeTransaction): Promise<CheckResult> {
// Автоматическое повышение требований при достижении порогов
if (tx.usdAmount >= AML_THRESHOLDS.FULL_KYC_REQUIRED) {
const kycStatus = await getKYCStatus(tx.userId);
if (kycStatus < KYCLevel.FULL) {
return {
action: "REQUIRE_KYC",
requiredLevel: KYCLevel.FULL,
message: "Для суммы свыше $3,000 требуется верификация",
};
}
}
// Скрининг при суммах выше $1,000
if (tx.usdAmount >= AML_THRESHOLDS.ENHANCED_SCREENING) {
const screenResult = await screenWallet(tx.destinationAddress, tx.asset);
if (screenResult.blocked) {
return { action: "BLOCK", reason: screenResult.reason };
}
}
return { action: "ALLOW" };
}
Что такое Source of Funds и когда он требуется?
Для крупных сумм (обычно от $10 000) требуется декларация источника средств. Это защищает обменник от обвинений в отмывании денег и снижает риск блокировки банковских счетов. Декларация действительна один год, затем её нужно обновить. Реализация:
interface SourceOfFunds {
source: "employment" | "business" | "investments" | "inheritance" | "other";
description: string;
estimatedMonthlyVolume: number;
supportingDocuments: string[]; // IPFS hashes или S3 URLs
}
async function collectSourceOfFunds(userId: string, amount: number): Promise<boolean> {
if (amount < SOF_THRESHOLD) return true;
const existingSOF = await db.getSourceOfFunds(userId);
// SOF valid если заполнен и не истёк (пересбор раз в год)
if (existingSOF && !isExpired(existingSOF, 365)) return true;
// Запрашиваем SOF через UI
await triggerSOFCollection(userId, { requiredFor: "transaction", amount });
return false;
}
Типичные ошибки при настройке лимитов
- Не учтена агрегация по активам. Ограничив только BTC, пользователь может обменять эквивалентную сумму в USDT. Наша система ограничивает совокупно в USD.
- Игнорирование межсетевых мостов. Если пользователь перевёл средства через мост, лимиты должны учитывать исходную сеть. Мы храним историю по всем сетям.
- Отсутствие идемпотентности при резервировании лимитов. Без идемпотентности повторные запросы могут уменьшить лимит дважды. Используем Redis с TTL.
Что входит в нашу работу
Мы предоставляем готовое решение под ключ:
- Архитектурный документ с описанием всех порогов и автоматических проверок.
- Исходный код с rolling windows, AML-скринингом и интеграцией через API.
- Развёртывание на вашем стенде и интеграция с KYC-провайдерами (например, Sumsub или Jumio).
- Обучение вашей команды (1 сессия) и 2 месяца сопровождения.
Наш опыт: более пяти лет в криптовалютной сфере, 30+ реализованных проектов, включая обменники и DeFi-протоколы. Гарантируем поддержку после внедрения.
Свяжитесь с нами для консультации — мы проанализируем ваш текущий стек и предложим оптимальную конфигурацию. Закажите внедрение, и ваша система лимитов будет готова к любым объёмам.