Модуль 10.1. Системный аналитик в банке/финтех (кейс-подход: «Сбер», «Тинькофф», «Альфа-Банк»)
Темы: платёжные сценарии, KYC/AML, интеграции с шинами. Справочники, транзакции, проводки, интеграции с бухгалтерией/BI. Артефакт: интеграционный контракт «заказ–счёт–оплата» (API/события/проводки/выгрузки). Практика: спецификация контракта + маппинг проводок.
Замечание: ниже — отраслевые паттерны. Конкретные регуляторные нормы и внутренние стандарты банков могут отличаться; согласовывайте с вашим отделом комплаенса/безопасности.
Картина домена: какие куски пазла вы держите как SA
Основные подсистемы:
- Оформление заказов (Order/Invoice) — e-commerce/маркетплейс или банковский маркет.
- Платёжный контур (Payments) — карты (МИР/Visa/MC), СБП, банковские переводы, внутренние кошельки.
- Антифрод + KYC/AML — санкционные/PEP-проверки, лимиты, скоринг.
- Учёт/бухгалтерия (GL/Subledger) — проводки, акты, НДС/комиссии, закрытие дня.
- ESB/Event Bus — Kafka/ESB для интеграций.
- DWH/BI — витрины фактов/измерений, сверки, отчётность.
Типичный жизненный цикл:
Заказ → Счёт/Инвойс → Оплата (authorize/capture или кредитовый перевод) → Постинг проводок → Выгрузки в DWH/BI → Сверки (референс с банком/PSP) → Закрытие дня.
Платёжные сценарии и статусы
Карта сценариев
|
Канал |
Характеристики |
Ключевые статусы |
|---|---|---|
|
Card Acquiring (AUTH→CAPTURE) |
Холды/списания, чарджбэки, 3DS, комиссионная модель |
NEW → AUTHORIZING → AUTHORIZED → CAPTURED → REFUNDED/CHARGEBACK/FAILED |
|
СБП (P2B) |
Синхрон/асинхрон, QR/коллбеки, лимиты |
NEW → PENDING → PAID/EXPIRED/FAILED |
|
Банковский перевод |
Долгая расчётка (D+1), платежки, референсы |
NEW → AWAITING_SETTLEMENT → SETTLED/REJECTED |
|
Внутренний кошелёк |
Мгновенно, KYC-лимиты |
RESERVED → DEBITED/CANCELLED |
Идемпотентность и корреляция
- Для создающих операций — Idempotency-Key (заголовок, 1..128 ASCII).
- В каждом запросе и событии — correlationId, businessKey (например, invoiceId), sourceSystem.
KYC/AML/Антифрод (в контуре SA)
KYC (знай своего клиента):
- Идентификация/верификация: паспорт/единый профиль/удалённая биометрия.
- Тиринг: уровни KYC → лимиты (дневные/месячные), допустимые операции.
- Актуализация данных: просрочка — перевод в ограниченный режим (freeze partial).
AML/мониторинг:
- Санкционные/PEP списки, неблагонадёжные деятельности, правила сценариев (DMN).
- События: aml.alert.created, статусы: PENDING_REVIEW/CONFIRMED/FALSE_POSITIVE.
- Блокировки: «заморозка» средств/операций до решения.
Антифрод:
- Онлайн-скоринг (feature store), поведенческие сигналы, deny-list/allow-list.
- Политики ответов: ALLOW/CHALLENGE/DENY.
SA фиксирует правила (DMN), точки вызова (sequence), данные (какие атрибуты уходят на скоринг), аудит и SLA разборов.
Справочники и мастер-данные (MDM)
|
Справочник |
Назначение |
Примечания |
|---|---|---|
|
Клиенты/KYC-профили |
UL + статусы KYC |
Идентификация, адреса, источники |
|
Продукты/Тарифы |
Комиссии/лимиты |
Версионирование тарифов, даты действия |
|
Валюты (ISO 4217) |
Денежные поля |
Отображение vs хранение (DECIMAL) |
|
Банки/БИК/Счета |
Платёжные реквизиты |
Валидация форматов/чек-сумм |
|
Причины возвратов/сторнова |
Отчётность, аналитика |
Коды/тексты для BI |
|
Юр.сущности/Договоры |
Учёт/налоги |
Реквизиты для GL/НДС |
Все справочники — версионируемы, с validFrom/validTo, owning-system и SLA обновления.
Транзакции и проводки: как «сойтись» с бухгалтерией
Подход
- Subledger (операционный учёт) — детально по операциям.
- GL (главная книга) — агрегированные/регламентные проводки.
- Двойная запись (double-entry), валютный учёт, НДС/комиссии.
Проводки (примерная схема)
|
Событие |
Дт |
Кт |
Сумма |
Комментарий |
|---|---|---|---|---|
|
AUTH (холд) |
40817 Клиентские |
913xx Забалансовый «Холд» |
amount |
Забаланс/резерв |
|
CAPTURE (списание) |
40817 Клиентские |
47422 Расчёты с ПС |
amount |
Списание клиента |
|
Комиссия банка |
47422 Расчёты с ПС |
70601 Доходы (комиссия) |
fee |
Доход банка |
|
REFUND |
47422 Расчёты с ПС |
40817 Клиентские |
refund |
Возврат клиенту |
|
Chargeback |
706xx/резервы |
47422 |
cbk |
Потери/резервы |
Конкретные номера счетов — пример; согласуйте с вашей бухгалтерией. SA фиксирует триггеры проводок и бизнес-ключи идемпотентности (чтоб не удвоить).
Идемпотентность постинга
- postingKey = <businessEventType>:<paymentId>:<amount>:<currency>
- Таблица posting_registry — контроль уникальности. Повтор того же события — не создаёт дубликаты.
Интеграции: шина/события/сверки
ESB/Event Bus (Kafka/ESB):
- Топики: payments.created.v1, payments.captured.v1, refunds.completed.v1, aml.alert.created.v1.
- Ключ партиционирования: paymentId/invoiceId.
- Гарантии: как минимум однократно + идемпотентные consumers.
- Outbox в платёжном СУБ-сервисе → надёжная публикация.
Сверки (reconciliation):
- Импорт реестров PSP/СБП (D+0/D+1), матчинга по rrn, authCode, сумме, дате.
- Результаты: matched/missing/amount_mismatch, тикеты на расследование.
Интеграции с DWH/BI:
- CDC таблиц payments, postings, refunds.
- Витрина fact_payments, измерения dim_customer, dim_tariff, dim_channel.
- SLA данных (например, D+1 09:00).
API/контракты и события (кейс «заказ–счёт–оплата»)
OpenAPI фрагменты (создание счёта и платежа)
openapi: 3.0.3
info: {title: Billing API, version: 1.0.0}
paths:
/v1/invoices:
post:
summary: Create invoice
parameters:
- in: header
name: Idempotency-Key
required: true
schema: {type: string, maxLength: 128}
requestBody:
required: true
content:
application/json:
schema:
type: object
required: [orderId, amount, currency]
properties:
orderId: {type: string, format: uuid}
amount: {type: string, pattern: "^[0-9]+(\\.[0-9]{2})$"}
currency:{type: string, enum: [RUB, USD, EUR]}
customerId: {type: string, format: uuid}
responses:
"201": {description: Created}
"409": {description: Duplicate}
/v1/payments:
post:
summary: Create payment for invoice
parameters:
- in: header
name: Idempotency-Key
required: true
schema: {type: string}
requestBody:
required: true
content:
application/json:
schema:
type: object
required: [invoiceId, method]
properties:
invoiceId: {type: string, format: uuid}
method: {type: string, enum: [CARD, SBP, TRANSFER, WALLET]}
responses:
"201": {description: Authorized or Captured}
"202": {description: Accepted (async, e.g., SBP or PSP timeout)}
"422": {description: Validation}
События (Avro/JSON Schema — фрагменты)
{
"title": "payment.captured.v1",
"type": "object",
"required": ["paymentId","invoiceId","amount","currency","capturedAt","method"],
"properties": {
"paymentId": {"type":"string","format":"uuid"},
"invoiceId": {"type":"string","format":"uuid"},
"amount": {"type":"string"},
"currency": {"type":"string"},
"method": {"type":"string","enum":["CARD","SBP","TRANSFER","WALLET"]},
"capturedAt": {"type":"string","format":"date-time"},
"correlationId": {"type":"string"},
"sourceSystem": {"type":"string"}
}
}
Ошибки/коды (единый словарь)
- AMOUNT_BELOW_MIN (422), METHOD_NOT_AVAILABLE (409), KYC_LIMIT_EXCEEDED (403), AML_REVIEW_REQUIRED (423), PSP_TIMEOUT (202).
Диаграммы (что показать команде)
Sequence «POST /payments (CARD)»:
Client → Payments API → AntiFraud (score) → PSP (authorize) → DB → Outbox → EventBus → PostingService (capture → postings)
Ветви: 3DS/Challenge, timeout/202 + ретраи, decline → FAILED.
State «Invoice»: NEW → ISSUED → PARTIALLY_PAID → PAID → EXPIRED/CANCELLED.
BPMN «Возврат»: оператор → проверка роли/лимита (DMN) → PSP refund → события/проводки → уведомления.
Риски (и как их гасить)
|
Риск |
Проявление |
Меры |
|---|---|---|
|
Дубликаты платежей |
Повтор запроса/коллбеков |
Idempotency-Key, идемпотентные события/постинги, корреляция |
|
Расхождения со сверками PSP |
Нет пары в реестре |
Единые ключи (RRN/AuthCode), инструменты расследования, SLA разборов |
|
Невыполнение KYC/AML |
Блокировка счетов/штрафы |
Жёсткие Entry-гейты KYC, DMN-правила, аудит, SLA manual review |
|
Таймауты PSP/СБП |
Зависшие статусы |
Асинхронные флоу (202+ретраи), outbox, дедупликация |
|
Ошибки проводок |
«дырки» в учёте |
Регистры идемпотентности, тесты проводок, сверка суб-книги с GL |
|
Несогласованность справочников |
Комиссии/НДС неверно |
MDM-владелец, версионирование, validFrom/To |
|
Утечки PII |
Логи/события с данными |
Маскирование, политики данных, токенизация, ограничение атрибутов |
|
Неполные данные в DWH |
BI отчёты «врут» |
CDC с дедупликацией, SLA D+1, мониторинги лагов |
Чек-лист SA для финтех-кейса
- Интеграционный контракт: OpenAPI/AsyncAPI/события/ошибки/идемпотентность.
- KYC/AML/Антифрод: точки вызова, DMN правила, статусы, аудит, SLA.
- Справочники/MDM: владельцы, версии, validFrom/To, источники.
- Состояния Invoice/Payment: диаграммы + инварианты.
- Проводки: триггеры, план счетов, идемпотентность постинга.
- Сверки: ключи матчей, отчёты, SLA расследования.
- Observability: SLI p95/error-rate, бизнес-метрики (доля успешных), трассировки.
- DWH/BI: модель фактов/измерений, SLA, словарь метрик.
- Безопасность: OAuth2/JWT, шифрование, маскирование PII, права (ABAC).
- Версионирование: semver для API/событий; CHANGELOG, депрекейшн-политика.
Практика: интеграционный контракт «заказ–счёт–оплата» (90–150 мин)
Задание: подготовьте спецификацию, включающую 5 артефактов.
- OpenAPI: /v1/invoices (создание/получение), /v1/payments (создание/статус), ошибки и заголовки Idempotency-Key, Authorization, X-Correlation-Id.
- AsyncAPI/JSON Schema событий: invoice.issued.v1, payment.captured.v1, refund.completed.v1 (минимальные поля+версии).
- Sequence-диаграмма: «Оплата для инвойса (CARD/SBP)» с ветвями timeout/decline/3DS, публикацией событий и вызовом PostingService.
- Проводки: таблица триггеров (capture/refund/fee) с дебет/кредит и бизнес-ключом идемпотентности.
- Выгрузка в DWH: словарь полей fact_payments (PK, FK, типы, обязательность), SLA обновления, политики дедупликации.
Критерии зачёта:
- Идемпотентность/корреляция в API/событиях и проводках.
- Диаграммы покрывают альтернативные ветви.
- Проводки согласованы с событиями (один бизнес-ключ).
- Прописаны ключи сверок с PSP/СБП.
- Есть NFR/SLA (latency, error-rate, CDC лаг).
Вопрос–Ответ
В: Чем оплата картой отличается от СБП с точки зрения интеграции?
О: Карта — обычно AUTH→CAPTURE (двухфазная), синхронный отклик + чарджбэки. СБП — асинхронный коллбек/поллинг, нет «AUTH», другие ключи матчинга, собственные лимиты.
В: Как правильно учитывать комиссию?
О: Разделять комиссию банка и комиссию мерчанта. Комиссии — отдельные проводки/события, ставки — из тарифного справочника (с validFrom/To).
В: Где проверять KYC/AML — до оплаты или после?
О: По риску: базовая KYC — до создания кошелька/счёта; AML-правила — перед завершением операции (capture/transfer). Решение фиксируется в DMN + аудит.
В: Что делать при таймауте PSP?
О: Возвращать 202 Accepted, ставить задачу в очередь, запускать ретраи (с джиттером), публиковать событие «в ожидании», ограничивать UX: «Ожидаем подтверждение до N минут».
В: Как избежать дублей проводок?
О: Вводим идемпотентный ключ для постинга (бизнес-ключ), регистр уникальности, повторная обработка — no-op.
В: Нужно ли отдавать в событиях PII клиента?
О: Нет. События — минимум атрибутов (ID/сумма/валюта/метод/время). Детали — по запросу через защищённые API.
Шпаргалка
- Idempotency + correlation — на каждом уровне: API, события, проводки, DWH.
- DMN для KYC/AML/антифрода — версионировать и тестировать.
- Invoice/Payment — чёткие статусы и инварианты; sequence с таймаутами/ошибками.
- Posting — двойная запись, регистр идемпотентности, триггеры от событий.
- Reconciliation — ключи матчей и SLA разборов.
- DWH — CDC, словарь метрик, SLA.
- Semver + CHANGELOG — для API/событий/моделей.
- Безопасность/PII — минимизация атрибутов, маскирование, аудит.
