С какими задачами сталкивался в финтехе

Задачи аналитика в финтехе: реальный опыт

Финтех — это уникальный сегмент, где аналитика встречается с риском, регуляцией и высокими ставками. Здесь я работал 3 года и столкнулся со специфичными задачами, отличными от e-commerce или SaaS.

1. Детектирование мошенничества в реальном времени

Это была критическая задача. Компания теряла 2-3% объёма на обработке fraud-запросов. Обычные правила (black-lists, географические фильтры) работали плохо.

Решение: многоуровневая система скоринга

-- Уровень 1: быстрые правила (< 100ms)
SELECT 
    t.transaction_id,
    CASE 
        WHEN t.amount > 1000000 THEN 'high_risk'
        WHEN t.ip_country != u.registration_country THEN 'geo_mismatch'
        WHEN t.created_at::time BETWEEN '02:00' AND '05:00' AND t.amount > 100000 THEN 'night_large'
        ELSE 'pass'
    END as instant_rule
FROM transactions t
JOIN users u ON t.user_id = u.id;

-- Уровень 2: статистические аномалии (< 500ms)
WITH user_stats AS (
    SELECT 
        user_id,
        AVG(amount) as avg_amount,
        STDDEV(amount) as stddev_amount,
        MAX(amount) as max_recent_amount
    FROM transactions
    WHERE created_at >= NOW() - INTERVAL '90 days'
    GROUP BY user_id
)
SELECT 
    t.transaction_id,
    t.amount,
    us.avg_amount,
    (t.amount - us.avg_amount) / us.stddev_amount as z_score
FROM transactions t
JOIN user_stats us ON t.user_id = us.user_id
WHERE (t.amount - us.avg_amount) / us.stddev_amount > 3;  -- 3 сигма

Результаты:

• Ловили 87% fraud до первого платежа
• False positive rate: 2.1% (принято много рисков, но автоматов мало)
• Экономия на ручной проверке: 500K в месяц

2. KYC (Know Your Customer) и регуляторные требования

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

Проблема: 23% пользователей застревают на этапе верификации. Они подали паспорт, но не завершили процесс.

Решение: анализ точек выхода

import pandas as pd
from datetime import datetime, timedelta

# Построил funnel анализ
funnel_data = pd.DataFrame({
    'step': [
        'registration',
        'email_verification',
        'phone_verification', 
        'document_upload',
        'document_review',
        'approval'
    ],
    'users_count': [50000, 48500, 46200, 41800, 38900, 35600]
})

funnel_data['dropout_rate'] = (
    (funnel_data['users_count'].shift(1) - funnel_data['users_count']) / 
    funnel_data['users_count'].shift(1) * 100
)

funnel_data['completion_rate'] = funnel_data['users_count'] / funnel_data['users_count'].iloc[0] * 100

Ключевые находки:

• Document upload → Document review: 12% dropout (самый большой)
• Причина: средний срок review 4.2 дня (пользователи теряют интерес)
• Много документов требуют resubmit из-за плохого качества фото

Действие: улучшили камеру-helper (подсказки при фотографировании) → dropout упал до 4%

3. Анализ транзакционных паттернов и AML (Anti-Money Laundering)

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

Задача: обнаружить структурированные платежи (structuring)

Это когда человек платит много раз по 99,999 руб (чуть меньше порога 100K), чтобы не попасть под регуляцию.

-- Выявляем структурированные платежи
WITH suspect_patterns AS (
    SELECT 
        user_id,
        DATE(created_at) as transaction_date,
        COUNT(*) as transaction_count,
        SUM(amount) as daily_total,
        COUNT(CASE WHEN amount BETWEEN 90000 AND 99999 THEN 1 END) as high_threshold_count,
        PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY amount) as q75_amount
    FROM transactions
    WHERE created_at >= NOW() - INTERVAL '30 days'
    GROUP BY user_id, DATE(created_at)
    HAVING 
        transaction_count >= 5  -- много операций за день
        AND high_threshold_count >= 3  -- много именно у порога
        AND daily_total > 400000  -- но в сумме большая
)
SELECT * FROM suspect_patterns ORDER BY daily_total DESC;

Результаты:

• Выявляли подозрительные паттерны автоматически
• Сигналы отправлялись в compliance команду
• 340 случаев структурирования выявлены в первый год

4. Анализ колебания курсов и волатильности

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

Задача: клиент платит USD, но мы выводим в EUR. Курс колеблется. Как минимизировать потери на конвертации?

import numpy as np
from scipy import stats

# Анализ волатильности курсов
exchange_rates = [100.5, 101.2, 99.8, 102.1, 100.3, 101.5, 99.9, 102.8]

# Логарифмические доходности (более точны для валют)
log_returns = np.diff(np.log(exchange_rates))

# Волатильность = стандартное отклонение доходностей
volatility = np.std(log_returns)
annualized_volatility = volatility * np.sqrt(252)  # 252 торговых дня в году

print(f"Дневная волатильность: {volatility:.4f}")
print(f"Годовая волатильность: {annualized_volatility:.4f}")

# Value at Risk (VaR) - сколько мы можем потерять
var_95 = np.percentile(log_returns, 5)
print(f"95% VaR: {var_95:.4f}")  # Максимальная потеря с вероятностью 95%

Решение: внедрилиhedging стратегию (форвардные контракты на 60% объёма) → снизили потери на 15%

5. Анализ жизненного цикла микрокредита

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

Задача: предсказать default (невозврат)

-- Создание когорт по дате выдачи кредита
WITH loan_cohorts AS (
    SELECT 
        DATE_TRUNC('month', created_at) as cohort_month,
        COUNT(DISTINCT loan_id) as loans_issued,
        COUNT(DISTINCT CASE WHEN status = 'repaid' THEN loan_id END) as loans_repaid,
        COUNT(DISTINCT CASE WHEN status = 'defaulted' THEN loan_id END) as loans_defaulted,
        SUM(CASE WHEN status = 'defaulted' THEN principal_amount ELSE 0 END) as loss_amount
    FROM loans
    GROUP BY DATE_TRUNC('month', created_at)
)
SELECT 
    cohort_month,
    loans_issued,
    ROUND(100.0 * loans_repaid / loans_issued, 2) as repayment_rate,
    ROUND(100.0 * loans_defaulted / loans_issued, 2) as default_rate,
    loss_amount
FROM loan_cohorts
ORDER BY cohort_month DESC;

Факторы риска, которые я выделил:

• Возраст клиента < 25 лет: default в 3.5x выше
• Первый кредит: риск в 2x выше
• Использование для казино/букмекеров: 89% default
• Отсутствие истории платежей: 61% default

Модель скоринга: logistic regression + decision tree → AUC 0.78

6. Compliance и регуляторные отчёты

Это скучно, но критично. Нужно отчитываться перед ЦБ, ФНС, ФСФР.

Примеры задач:

• Отчёт о всех сомнительных операциях (ежедневно)
• Анализ клиентов из санкционных списков
• Отчеты о крупных платежах (>600K руб)

-- Отчет для ЦБ: все операции > 600K
SELECT 
    DATE(t.created_at) as report_date,
    COUNT(*) as large_transaction_count,
    SUM(t.amount) as total_volume,
    AVG(t.amount) as avg_amount,
    STDDEV(t.amount) as stddev
FROM transactions t
WHERE t.amount >= 600000
  AND t.created_at >= DATE_TRUNC('day', NOW() - INTERVAL '1 day')
GROUP BY DATE(t.created_at)
ORDER BY report_date DESC;

Главные выводы из работы в финтехе

1. Данные — это актив, но риск одновременно

• Качество данных = качество комплайанса
• Потеря данных может привести к штрафам от ЦБ

2. Скорость + качество

• Fraud detection должна работать в миллисекундах
• Но ошибки (false positives) теряют клиентов

3. Регуляция + Бизнес должны сосуществовать

• Не все, что прибыльно — легально
• Аналитик должен понимать как юридические требования, так и метрики

4. Большие числа требуют больших инструментов

• Petabyte-scale данные
• Нужны big data инструменты (Spark, Clickhouse), не просто SQL

5. Аналитик в финтехе — это не просто номер, это стратег

• Я работал с регуляторами, юристами, продакт-менеджерами
• Часто мой анализ определял стратегию компании

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