AWS опублікувала архітектуру AI-агентів для KYC/KYB
AWS показала робочу мультиагентну систему перевірки клієнтів: п'ять незалежних агентів (перевірка медіа на негатив та інші) паралельно досліджують заявника. Працює на Bedrock AgentCore, Strands Agents SDK і Step Functions; фінальне рішення завжди за людиною. Поглиблена перевірка, яка забирала дні роботи аналітика, зводиться до 5 хвилин перегляду готового висновку замість 45-60 хвилин ручного аналізу.
Складні випадки — заможні клієнти, багатоструктурні корпорації — змушують банки обмежувати глибину перевірки або відмовляти невигідним клієнтам. AWS опублікувала не концепцію, а метод разом з кодом.
Чому перевірка "складних" клієнтів настільки дорога
За словами AWS, для приватних клієнтів і малого бізнесу індустрія вже вирішила проблему перевірки: типові випадки обробляють автоматизовані системи на правилах. Але щойно клієнт випадає з "щасливого шляху" — заможна особа, велика корпорація з багаторівневою структурою власності, — перевірка стає ручною роботою аналітика: читання документів, перехресна звірка джерел, оцінка "чи має це сенс".
Один випадок поглибленої перевірки (enhanced due diligence) може забирати дні роботи старшого аналітика. Помножте на тисячі кейсів на рік і додайте дефіцит кваліфікованих комплаєнс-фахівців — і вартість якісної перевірки робить цілі сегменти клієнтів комерційно невигідними. Саме тому, за даними AWS, деякі банки обмежують глибину перевірки або взагалі відмовляють клієнтам, яких не можуть виправдати з точки зору витрат.
Як розподілені ролі між п'ятьма агентами
Кожна з п'яти перевірок — окрема багатоагентна система зі своєю логікою. У скринінгу негативних медіа один агент паралельно шукає за темами ризику (шахрайство, відмивання коштів, фінансування терроризму, хабарництво, санкції) — це скорочує 30-хвилинний пошук до приблизно 3 хвилин. Другий агент читає весь знайдений матеріал і об'єднує його у структуровані висновки — типово 3-8 окремих висновків із понад 50 знайдених посилань. Третій застосовує політику банку з бази знань і виносить вердикт: CLEAR, ESCALATE або INCOMPLETE.
Скринінг санкцій побудований за принципом "чотирьох очей": один агент оцінює збіг, повністю незалежний другий агент перевіряє його аргументацію, і якщо перевіряючий її відхиляє, справа йде до людини. Обидва агенти не мають доступу до жодних інструментів — усі докази вже вбудовані у запит.
У перевірці бізнес-даних AWS наводить приклад: заявник вказав, що продає алкоголь, а його код класифікації діяльності (SIC) відповідав "ресторану без ліцензії", і сайт компанії теж показував алкоголь у меню. Агент зафіксував суперечність одразу за трьома джерелами і передав справу на ескалацію. У перевірці структури власності окремий агент рекурсивно проходить реєстри, визначає директорів і кінцевих бенефіціарів через холдингові компанії, розраховує, чи власник підпадає під поріг (понад 25% частки), і перевіряє наявність потрібних документів. У перевірці джерела доходів система оцінює правдоподібність за чотирма вимірами одразу — приклад невідповідності з матеріалу: річний дохід 1 млн фунтів у барбершопі, який працює лише рік.
Метод, а не готовий продукт
- Детерміністичні дії (отримати запис компанії, розрахувати частку власності, звірити ім'я зі списком санкцій) виконує звичайний код — без штучного інтелекту й ризику "галюцинацій"
- Судження, що вимагає міркувань (чи є стаття негативним медіа, чи правдоподібне джерело доходів), доручають окремому агенту з чіткою єдиною метою
- Пошук доказів і оцінку доказів розділяють між різними агентами: якщо пошуковий агент повертає нерелевантний контент, аналітичний агент відхиляє його на межі перевірки, а не міркує над цим
Матеріал описує референсну реалізацію на синтетичних даних (імітація відповідей британського реєстру Companies House), а не систему, що вже працює в конкретному банку; дати запуску й вартості впровадження в джерелі немає.