Архитектура

Real-time decisioning архитектура для банка

Fraud, AML, credit, NBA, retention triggers — все требуют sub-second decisioning. Архитектура слоя в банке.

Обсудить задачу

Что такое real-time decisioning в банке

Каждая customer interaction имеет potential decision: approve transaction or block, show offer, escalate, log audit. Без centralised layer — decisions scattered, inconsistent.

Banking decisioning консолидирует: trigger event → context fetch → policy + model evaluation → decision + audit.

Структурные компоненты

Trigger ingress. Events из event bus, channels, transactions.

Context fetch. Profile из CDP, current state (balance, recent activity, active cases).

Policy engine. Decларative rules (regulatory, risk appetite, customer preferences). Изменяются без deploy.

Model serving. ML models (PD, fraud score, propensity). Versioned, A/B-able.

Decision logic. Combination policies + model scores + business rules.

Audit trail. Каждое decision с full input, models, policies, output, owner.

A/B framework. Decision compared с alternative для learning.

Latency budget

Banking specific:

  • Card authorization: <500ms end-to-end (network limit).
  • Online banking transaction: <1s acceptable.
  • Credit decision retail: <5s.
  • Mobile app NBA: <500ms.

Budget allocation:

  • Trigger ingress 20-50ms.
  • Context fetch 30-80ms.
  • Model serving 20-100ms.
  • Policy evaluation 10-30ms.
  • Decision logic 10-30ms.
  • Audit (async) 10-30ms.

Где банк-specific сложнее

Regulatory traceability. Каждое automated decision должно быть explainable per regulator (особенно для credit и AML).

Model bias. Credit models особенно — disparate impact monitoring обязательно.

Override audit. Manual overrides — full chain of approval.

False positive cost. Block legitimate transaction — customer churn.

Где обычно ломается

Latency не measured — каналы timeout.

Policies в коде — изменения требуют deploy.

Models не retrained — accuracy decay unnoticed.

Audit incomplete — investigation cases impossible.

A/B testing невозможен — product не учится.

Operating model

Owner — Head of Decisioning, между risk и technology.

Teams: platform engineering, decision science, policy management, channel integration.

Routine — weekly decision review, monthly model review.

Связанное

← Назад

Готовы обсудить вашу задачу?

Расскажите, что не работает или что нужно построить. Первый разговор — без обязательств.

Обычно отвечаю в течение нескольких часов

Обсудить задачу
Выберите удобный способ связи
Telegram
Быстрый ответ
Быстро
WhatsApp
Голос и документы
📞
Позвонить
+998 99 838-11-88