Взаємодія інтеграційної системи FastTack з банківською системою (комплексом) У процесі токенізації є три основні учасники: запитувач токенів (Token Requestor), постачальник токенів (Token Service Provider) та банк-емітент (FastTack). Token Requestor (TR) Token Requestor (TR) - провайдери цифрових гаманців, інтернет-магазини, інші провайдери сервісів. Токеном замовником можуть бути як традиційні учасники платіжної індустрії, так і нові учасники, що пропонують різні інновації. Новими учасниками є постачальники цифрових гаманців, емітенти, що пропонують власникам карток власні мобільні платіжні додатки, великі інтернет-майданчики, що приймають картки. Замовник токенів має прямі відносини з клієнтом або керує ними від імені продавця. Замовник токенів повинен бути зареєстрованим учасником технологічного процесу токенізації в платіжних системах. Провайдер цифрового гаманця DWP (ApplePay, GooglePay), що підтримує технологію токенізації картки. Забезпечує інтерфейс з клієнтом через мобільний застосунок. Token Service Providers (VTS/MDES) Token Service Providers (VTS/MDES) - сервіс токенізації VISA та Mastercard, що замінює реальні дані картки (FPAN) на унікальний токен (DPAN) за допомогою захищеного мережевого шлюзу та шифрування. Issuer Bank Issuer Bank - банк-емітент підтверджує можливість токенізації платіжної картки відповідно до запитів від сервісу токенізації та відповідає за активність картки та за аутентифікацію клієнта. Процес взаємодії між учасниками забезпечується інтерфейсами API, API 1, API 2, API 3. API – інтерфейс між Token Requestor та Token Service Providers; API 1 (Visa Issuer API / MDES Pre-Digitization API) – інтерфейс між Token Service Providers та Bank Issuer (Fasttack); API 2 (Universal Issuer API) – інтерфейс між Fasttck та банківською системою яка відповідає за емісію та управління картками. API 3 (Push/InAPP Provisioning API) – інтерфейс між Fasttck та банківською системою яка відповідає за мобільний додаток банку. Ініціатором процесу токенізації зазвичай виступає Token Requestor. Навіть у тих випадках, коли клієнт спочатку передає Token Requestor свої особисті дані та дані картки, ініціатором токенізації буде Token Requestor. Token Service Provider отримує дані картки від Token Requestor, після чого починається процес Provisioning. Дуже часто Token Requestors, які є провайдерами гаманця, називають Digital Wallet Providers або Third Party Wallets. До таких гаманців відносять: Google Pay, Apple Pay, Samsung Pay, Garmin pay, Swatch Pay, Xiaomi Pay. Процес Provisioning поділяється на кілька послідовних запитів до системи Bank Issuer. Обробку всіх запитів від Token Service Provider забезпечує інтеграційна система FastTack. Основні завдання, що вирішуються в системі FastTack: Підтримка API та необхідних функцій для процесів токенізації карток та ідентифікації власників карток (Visa Issuer API / MDES Pre-Digitzation API); Підтримка API та необхідних функцій для управління життєвим циклом токенів (Visa Web Service API / MDES Customer Service API); Підтримка криптографічного захисту інформації, передбаченого специфікаціями зазначених API. Надання універсального API (Universal Issuer API) для реалізації всіх необхідних функцій на зовні існуючих внутрішніх підсистемах банку; Надання WEB-інтерфейсу для адміністративних і користувацьких функцій; Підтримка логіки обробки повідомлень від VTS/MDES: асинхронне надходження повідомлень, втрата повідомлень, незавершений процес токенізації картки та генерація повідомлень для банку; Реалізація криптографічної підтримки (генерація зашифрованих даних) у випадку, коли банк реалізує, наприклад, надання всередині додатка, наприклад, токенізацію карток у гаманці Apple Pay (додавання карток до гаманця) через свій мобільний додаток. Система FastTack забезпечує універсальний інтерфейс із системою або системами банку. Зазвичай під системами банку розуміють такі системи: система управління емісією карток, таку систему називають CMS (Card Management System); система відправки повідомлень клієнту через СМС, таку систему називають SMS Gate (Messenger); система авторизації карток, таку систему називають Authorization System. Така система може бути безпосередньо в банку або в процесинговому центрі. Банк-емітент як учасник процесу токенізації об'єднує кілька систем: DSP Fasttack - інтеграція з TSP (VTS, MDES) і банківськими системами; Card Management System - управління стратегією емісії карток, продуктами, балансами та ажурних до карток; SMS Gate - відправка смс повідомлень клієнту; Authorization System- забезпечує процес підтвердження можливості оплати банківською карткою в торгових мережах, банкоматних мережах, електронній комерції та в інших платіжних схемах. Завдання, що реалізуються FastTack, можна розділити на 3 процеси: Процес токенізації картки TLCM життєвий цикл токена Push-Provisioning Технологічними особливостями системи FastTack є контроль послідовності запитів процесу токенізації, забезпечення стабільного рівня безпеки обробки даних, постійний моніторинг працездатності системи та всіх її елементів. Системи банку обслуговують всі запити щодо токенізації, пов'язані з перевіркою можливості токенізації, отриманням даних про картковий продукт і перевіркою активності картки в технологічній операції банківської інфраструктури. Інтеграція Банку Емітента з сервісами токенізації TSP (MDES/VTS). Процес токенізації (з мінімальними параметрами ризику) Перший запит — перевірка Confirm Provisioning можливості оцифрування картки та перевірки фінансових параметрів клієнта (власника картки). Банк-емітент реалізує свою стратегію емісії карток. Відповідно, не весь діапазон номерів карток може підпадати під можливість токенізації. Щодо власника картки, у банку також можуть бути питання. Всі дозвільні схеми визначає банк. Якщо банк підтверджує можливість токенізації картки, він повертає TSP номер продукту картки (дизайн картки) і номер телефону (повний номер залишається в системі Fasttack і 4 останні цифри номера будуть відправлені в TSP). Другий запит — перевірка активності картки в процесінгу. Виконується перевірка номера картки, терміну дії та коду безпеки. У разі успішної перевірки картки повертається позитивна відповідь і тільки після цього кроку буде виконуватися третій запит. Третій запит - TSP генерує OTP (one time password) і відправляє запит з OTP на банк емітент . Банк емітент в свою чергу повинен перенаправити його клієнту , використовуючи систему SMS Gate. Клієнт, отримавши OTP повинен ввести його в гаманці TR. Потім TSP порівнює два значення. Порівняння значення OTP є важливим фактором аутентифікації. Ця дія підтверджує, що саме власник картки виконує токенізацію в гаманці. Четвертий запит – повідомлення про активацію токена, банк-емітент отримує Ref_Token, DPAN, Exp, Token Status=Active. Сценарії процесу токенізації Токенізація через глобальні гаманці: Apple wallet, Google wallet. Параметри, які впливають на сценарій токенізації. panSource – джерело введення картки; K - номер картки введений вручну; M - номер картки переданий через мобільний додаток банку (Push Provisioning, In-App Provisioning). tokenizationPath - рекомендований шлях токенізації; GREEN - токенізація може бути проведена без додаткової аутентифікації клієнта; YELLOW - рекомендується провести токенізацію з додатковою аутентифікацією клієнта стандартним способом; ORANGE - рекомендується провести токенізацію з додатковою аутентифікацією клієнта за укладеною процедурою; RED - рекомендується відмовити в проведенні токенізації. walletId - ідентифікатор TR; 103 - Apple Pay; 216 - Android Pay; otrReason – тип процесу; PROVISIONING, PAYMENT, TOKEN_DEVICE_BINDING, CARDHOLDER_SETUP, TRUSTED_LISTING_ENROLLMENT, FPAN_NOTIFICATIONS; Decision – рішення банку. APPROVED – запитана дія може бути проведена без додаткової аутентифікації клієнта; REQUIRE_ADDITIONAL_AUTHENTICATION - запитана дія має бути проведена з додатковою аутентифікацією клієнта; DECLINED - запитана дія не може бути проведена. Сценарій - зелений шлях Токенізація виконується через банківський додаток. Верифікація та аутентифікація клієнта виконана. З точки зору банку клієнт може токенізувати обрану ним картку. Картка активна і фінансові показники клієнта влаштовують банк. Сценарій - жовтий шлях Токенізація виконується через глобальний гаманець Apple Pay, Google Pay. Клієнт вводить номер картки через інтерфейс гаманця. Облікової записи клієнта в нормі. Необхідно провести аутентифікацію клієнта через OTP. Сценарій - помаранчевий шлях Токенізація виконується через глобальний гаманець Apple Pay, Google Pay. Клієнт вводить номер картки через інтерфейс гаманця. Облікової записи клієнта не в нормі. Необхідно провести додаткову аутентифікацію клієнта за посиленим сценарієм через кол-центр банку. Сценарій - червоний шлях Токенізація виконується через глобальний гаманець Apple Pay, Google Pay. Клієнт вводить номер картки через інтерфейс гаманця. Облікової записи клієнта з підозрою на шахрайство. Рекомендація – токенізацію відхилити. Процес життєвого циклу токена Розрізняють два види життєвого циклу картки: повний та управлінський. Управлінський є частиною повного шилу токена. Повний життєвий цикл токена Повний життєвий цикл токена складається з 7 ключових етапів: Token Provisioning (Створення токена); Token Activation (Активація); Token Usage (Використання токена); Token Suspension (Призупинення); Token Resumption (Відновлення); Token Replacement (Прив'язка нової карти до токена); Token Deletion / Deactivation (Видалення). PROVISIONING — СТВОРЕННЯ ТОКЕНА Токен створюється через Token Requestors: Apple Pay, Google Pay, Samsung Pay, Click-to-Pay, Merchant Tokenization (Card-on-File для Amazon, Uber), Secure Element токени (HCE, eSE). Схема процесів: Cardholder вводить \відправляє PAN в гаманець /мерчанта; Token Requestor відправляє в Token Service Provider VTS/MDES; TSP надправляє запит Bank Issuer; Bank Issuer виконує аутентифікацію (OTP, App Confirmation, 3DS challenge); TSP створює: DPAN (Device / Payment Token), Token Metadata , Cryptographic Keys (dCVV, AAV, CVC3). Токен отримує статус: «Created». ACTIVATION — АКТИВАЦІЯ ТОКЕНА Активація відбувається тільки після успішної верифікації власника картки. Apple Pay / Google Pay використовують шляхи: Green, Yellow, Orange. У разі успішного процесу аутентифікації клієнта активується токен. Токен отримує статус: «Active / Provisioned». USAGE — ВИКОРИСТАННЯ ТОКЕНА Використання токена здійснюється в мережах прийому карток: NFC транзакцих (Apple/Google Pay); E-commerce транзакцiях; In-app платіжних сценаріях; Card-on-File у великих мерчантів. Кожна транзакція містить дані: одноразова криптограма, Token Requestor ID, Device fingerprint SUSPENSION — ПРИЗУПИНЕННЯ ТОКЕНА Токен може бути тимчасово призупинений, але не видалений. Токен у такому статусі не використовується в транзакціях. Причини, за якими використовується такий статус: Втрата/крадіжка телефону/тимчасове невикористання; Suspicious activity (фрод-параметри); Занадто багато невдалих криптограм; Пристрій jailbreak / root; Зміна безпеки Secure Element; Device lockout (блокування пристрою); Вимога регулятора/платіжних систем. Токен отримує статус: «Suspend». RESUMPTION — ВІДНОВЛЕННЯ ТОКЕНА Токен можна відновити, якщо причина була тимчасовою: Телефон знайдено; Блокування пристрою знято; Емітент зняв фрод-блокування; Видалене lock/unlock (наприклад, через iCloud). Токен отримує статус: «Active». REPLACEMENT TOKEN — ПЕРЕПРИВ'ЯЗКА КАРТКИ ДО ТОКЕНУ Заміна картки до токену виконується в двох ситуаціях: 1. PAN був замінений емітентом (reissue). Можливі причини для виконання даної операції: закінчився термін дії картки; зміна PAN через фрод; заміна картки через втрату/крадіжку; перехід на новий BIN; перевипуск чіпа. 2. Вимога платіжних систем — оновлення криптографічного профілю токена. Наприклад: зміна ключів токенізації (issuer keys); зміна token requestor security level; переведення токена на інший cryptogram format. Токен отримує статус: «Active». DELETION / DEACTIVATION — ВИДАЛЕННЯ ТОКЕНА Причин видалення токена може бути багато, основні: Видалення картки з Wallet; Емітент замінив картку (reissue); PAN expired; Зміна номера картки (lost/stolen); Токен закритий через фрод; Користувач відключив пристрій. Статус токена: «Deleted». Управлінський життєвий цикл токена Управлінський цикл включає: Suspend (призупинення); Resume (відновлення); Replacement (переприв'язка); Delete (видалення).