Слой принятия решения о платеже
Между моментом, когда платёж предложен, и моментом, когда деньги действительно уходят, кто-то должен решить, допустима ли эта операция вообще. Исторически это решение часто было встроено в другие продукты — AP-систему, банк, антифрод или внутренний автоматизированный сценарий. По мере того как инициация становится более автоматизированной и разнородной, этот шаг всё логичнее рассматривать как самостоятельный слой.
Определение
Слой принятия решения о платеже (payment decision layer) — это система, расположенная между инициацией и исполнением. Она проверяет платёжный запрос вместе с дополнительным контекстом, применяет политику и возвращает финальное решение по каждому запросу, сохраняя запись, пригодную для аудита.
В этой базе знаний используются четыре исхода:
- Allow — запрос проходит политику и передаётся на исполнение.
- Hold — запрос приостановлен до получения дополнительной информации или переоценки по времени.
- Block — запрос нарушает жёсткое правило. Платёж не исполняется. Решение и его причина фиксируются.
- Escalate — запрос выходит за пределы автоматического решения и направляется заданному человеку или системе для явного одобрения.
Слой может также возвращать коды причин, указатели на версию политики и подписанные подтверждения решения.
Чем он не является
- Не фрод-движок. Скоринг мошенничества вероятностный, рекомендательный и обычно работает на сигналах карточных сетей уже после предъявления карты. См. Почему антифрод — это не принятие платёжного решения.
- Не оркестратор. Оркестрация определяет, как маршрутизировать уже одобренный платёж. Слой принятия решения определяет, должен ли платёж происходить.
- Не банк, не процессор, не эмитент. Он не держит средств, не управляет рельсами и не имеет прямой связи с сетями.
- Не универсальная система авторизации. Общие policy-движки отвечают на вопрос «может ли пользователь выполнить действие над ресурсом». Слой принятия решения о платеже понимает контрагентов, суммы, валюты, мандаты, санкционный статус, центры затрат и то, как всё это взаимодействует в конкретном событии движения денег.
Типичные входы
- Платёжный запрос — сумма, валюта, контрагент, рельса.
- Идентификация инициатора — агент, автоматизированный сценарий, сервисный аккаунт или человек.
- Доказательства мандата или согласия, если они доступны (например, мандаты AP2).
- Политика оператора — пороги, списки разрешённых и запрещённых контрагентов, правила центров затрат.
- Внешние сигналы — санкционные списки, статус KYC / KYB, риск кошелька, фрод-скор как один из входов.
- Контекст — время, частотность, предыдущие решения по связанным платежам.
Типичные выходы
- Один из четырёх исходов.
- Код причины.
- Указатель на версию политики, которая породила решение.
- Подписанная запись, пригодная для аудита, сверки или диспута.
Почему этот слой становится виден именно сейчас
Когда инициацию в основном формировали люди в специализированных инструментах, логика решения могла оставаться внутри этих инструментов. Когда запросы приходят от агентов, автоматизированных сценариев, ERP-прогонов, API-вызовов и протоколов, становится оправданным единый интерфейс принятия решения, через который они все проходят.
Несколько смежных изменений — концепция мандатов в сетевых протоколах, аргумент о необходимости архитектурного отделения принятия решения от исполнения, новые схемы идентификации агентов — это входы, которые слой потребляет, а не сам слой.
Где здесь Froddy
Froddy относится к этому слою: система находится перед исполнением платежа, применяет политику к запросу и возвращает одно из четырёх решений с кодом причины и записью для аудита. Исполнение, маршрутизация и движение средств остаются в существующей инфраструктуре клиента.
Связанные страницы
Change log
- 2026-04-18 — Первичная публикация.