Одна інтеграція може читати довідку, готувати рекомендацію, змінювати клієнтський запис або запускати рух коштів. Їх не слід об’єднувати одним дозволом «агенту доступно». Почніть із рішень, на які він впливає, та наслідків помилки чи затримки.
Це інженерна рамка вибору контролів, а не класифікація за назвою галузі. Роль системи, призначення, дані та застосовні обов’язки потребують окремого розгляду. Працездатний прототип не доводить правомірність обробки чи відповідність регулюванню.
Розділіть дії за наслідками
Окремо розгляньте читання даних, аналіз, чернетку, зміну внутрішнього запису, яку можна скасувати, повідомлення клієнту, зміну рахунку та платіж. Врахуйте суму, одержувача, чутливість, можливість скасування, вплив на клієнта та чи можна виправити дію до зовнішнього ефекту. Кредитні рішення, виявлення шахрайства й підтримка — різні сценарії.
Для кожного класу визначте типовий шлях: дозволити з аудитом, дозволити за умов, зупинити для погодження або заборонити. Невідомий клас не має успадковувати ширший дозвіл. Ізолюйте його, поясніть причину та призначте власника класифікації й перегляду правила.
Розмежуйте право читати дані, готувати пропозицію, погоджувати її та виконувати. Один обліковий запис із усіма повноваженнями ускладнює контроль і розбір помилок. Узгодьте службові ролі з реальним процесом, перевірте відкликання доступу й документуйте аварійний доступ окремо від звичайного.
Зробіть погодження поінформованим
Перед значущою операцією рецензент має бачити дію, ціль, суму чи змінюване поле, підставу, джерела, версію правила та можливий наслідок. Дайте змогу відхилити, змінити або передати запит. Записуйте рішення й контекст, який бачив рецензент; натискання кнопки не пояснює, що саме погоджено.
Для запиту визначте строк дії й поведінку без відповіді. Для важко зворотної фінансової дії проєктним вибором може бути зупинка чи ескалація, але правило має підтвердити власник процесу. Перевірте, що прострочене погодження не виконується згодом, а повтор не створює другу операцію.
Після дії перевірте не лише відповідь API, а й стан у системі-джерелі. Частковий запис, затримка або відкат можуть залишити клієнтський рахунок у несподіваному стані. Визначте, хто звіряє розбіжність, як призупиняється наступна операція та який доказ зберігається для виправлення.
Пов’яжіть правило з результатом
Зв’яжіть запит, контекст, версію політики, вердикт, погоджувача, виклик інструмента й результат одним ідентифікатором. Розрізняйте успіх, відмову, скасування та невідомий стан після тайм-ауту. Зберігайте лише потрібні дані з належними правами та строком.
До запуску перевірте дозвіл у межах умов, перевищення порогу, відсутнє джерело, відкликані права, невідомий клас і повтор після втрати відповіді. Команда має відновити, хто що бачив і чому дія відбулася. Наявність журналу чи чеклиста сама не підтверджує відповідність.
Переглядайте класи разом зі змінами продукту, лімітів і процесу. Операція, яка була зворотною у тестовому середовищі, може мати зовнішній ефект у реальному потоці. Залучіть власника процесу до повторної перевірки порогів і винятків; не переносіть налаштування з іншого фінансового продукту без оцінки.
Що можна зробити зараз
Підготуйте таблицю «клас дії / режим / хто погоджує / потрібні докази / тайм-аут / відкат». Попросіть власників процесу, безпеки, даних і юристів підтвердити межі до підключення запису чи платежів. Почніть з одного обмеженого сценарію та негативних перевірок.
