QR-коди для банків: сценарії, ризики та засоби контролю

QR-коди для банків бувають двох дуже різних видів. Платіжний код несе переказ SEPA всередині візерунка, а банківський застосунок читає його офлайн. Кожен інший код, який друкує банк, на дверях відділення, банкоматі, виписці чи флаєрі зі встановленням застосунку, - це просто посилання в регульованій комунікації з клієнтом. Перший вид потребує правильного форматування. Другий - керування доступом. Хто ним володіє? Хто може його змінити? І що доводить, куди він вів минулого березня?

Саме тут більшість порад про "QR-коди у фінансах" стають розпливчастими. Популярні посібники добре охоплюють сценарії використання, а допис Bitly для США - слушний приклад, але про журнали аудиту, контроль змін чи правила ЄС вони кажуть мало. Я працюю з боку відповідності, тому саме на цьому витрачу час, поруч із практичними сценаріями для банків, фінтех-компаній і страховиків.

Якщо ваша команда нова в механіці, основи охоплюють матеріали що таке QR-код та динамічні й статичні QR-коди. Для ширшого погляду на рівень посилань у регульованому продукті супровідний матеріал - скорочувачі URL для фінтеху.

Де QR-коди заслужили своє місце в банківській справі

QR-код вартий друку, коли він прибирає набір тексту в момент, коли клієнт стоїть перед чимось фізичним. У банківській справі таких моментів багато, але лише деякі заслуговують на код.

Платежі та рахунки

Найсильніший випадок - платіжний код. Уявіть рахунок-фактуру або плакат для пожертв. QR-код EPC дає клієнтові змогу відсканувати, побачити переказ, наперед заповнений у банківському застосунку, і підтвердити. Тут нічого не скорочується і не відстежується, і це задумано. Тримайте його окремим кодом і вимірюйте сторінку навколо нього окремим посиланням.

Онбординг і завантаження застосунку

Код на листівці у відділенні або на носії картки, що відкриває потрібну сторінку в магазині застосунків, - друге за силою застосування. Один код може спрямовувати відвідувачів iPhone і Android у правильний магазин, що розбирає матеріал QR-коди для завантаження застосунків. Тримайте код спрямованим на магазин або на ваш власний домен, а не на сирий URL стороннього постачальника онбордингу, щоб ви могли змінити постачальника без повторного друку.

Посилання для сервісу у відділеннях і на банкоматах

Запис на прийом, "знайти відділення" та "повідомити про проблему з цим апаратом" - природні сценарії. Вони також є найбільш піддатливими до втручання розміщеннями. Наліпка біля банкомата лежить на видноті, і ніхто за нею не стежить. Докладніше про це нижче.

Виписки та активація картки

Код на паперовій виписці може відкривати вхідні захищених повідомлень або сторінку довідки. Тримайте номери рахунків, імена й токени поза URL: вони потрапляють у журнали сервера та заголовки реферера, і це проблема мінімізації даних за GDPR раніше, ніж щось інше. Для активації картки моє правило просте. Код може відкривати застосунок банку або довідкову сторінку активації. Він ніколи не повинен відкривати сторінку, що просить повний номер картки та PIN, бо саме цього попросить і підробка, а клієнти вже не можуть відрізнити одне від іншого.

Страхові претензії та обслуговування

Страховики використовують коди на документах полісів і листах про претензії, щоб відкрити форму претензії або сторінку завантаження документів. Діє те саме керування: лист із полісом роками лежатиме в шухляді, тож ціль має лишатися доступною та під вашим контролем доти, доки існує лист.

Платіжні коди проти кодів-посилань

Розглядайте їх як два продукти з двома профілями ризику. Діаграма показує різницю з першого погляду.

Платіжний код статичний і офлайн. Змінити його ціль не можна, рахувати сканування не можна, а хибний IBAN означає повторний друк. Платника захищає екран підтвердження. Банки єврозони тепер мають пропонувати перевірку отримувача (Verification of Payee) за Регламентом ЄС про миттєві платежі (Регламент (ЄС) 2024/886, стаття 5c), що порівнює ім'я отримувача з IBAN, перш ніж платник авторизує переказ. Q&A щодо впровадження Європейської комісії встановлює строк для сторони-відправника в єврозоні на 9 жовтня 2025 року. Це допомагає проти підміни наліпки, описаної нижче, але лише якщо платник прочитає результат.

Код-посилання - навпаки. Це звичайний URL, тож між скануванням і ціллю стоїть редирект. Цей редирект - точка контролю. Його можна переспрямувати, коли сторінка переїжджає, вимкнути, коли щось іде не так, і порахувати по кожному відділенню та розсилці, що несе код. Він також є вразливістю, якщо ніхто ним не володіє.

Ризики, специфічні для банків

Квішинг (quishing) - це фішинг через QR-код. FTC задокументувала, як шахраї ховають шкідливі посилання в QR-кодах, а механіку охоплює наш посібник про квішинг. Для банку важливі три варіанти.

• Накладні наліпки. Підроблений код, приклеєний поверх справжнього на банкоматі, вікні відділення чи надрукованому рахунку. Легітимний код під ним лишається недоторканим.
• Домени-двійники. Код в електронному листі чи SMS, що відкриває yourbank-secure.example замість вашого домену.
• Перенаправлення платежу. Статичний платіжний код на папері, закритий кодом з іншим IBAN.

Незручна правда в тому, що динамічний код не зупиняє накладення. Код зловмисника належить йому, а не вам, і ви не можете його переспрямувати. Що ви можете - зробити накладення легшими для помічення й дешевшими для відновлення:

1. Друкуйте домен цілі простим текстом поруч із кожним кодом, щоб невідповідність була видимою.
2. Використовуйте етикетки із захистом від втручання для розміщень на банкоматах і у відділеннях та ведіть журнал перевірок так, як ви ведете журнал перевірок банкоматів.
3. Використовуйте один брендований домен для всіх кодів, спрямованих на клієнтів, щоб клієнти його вивчили. Власні домени для коротких посилань пояснюють, чому це важливіше за будь-яке інше окреме налаштування.
4. Простими словами кажіть клієнтам, чого легітимне сканування ніколи не просить: PIN, повного номера картки, одноразового коду.

Шаблон, якого слід уникати, - коли кожен флаєр, плакат і вкладка до виписки використовують інший загальний короткий домен. Тоді ніхто, зокрема працівники відділень, не може сказати, який із них справжній, а клієнти не можуть навчитися, як виглядає справжній код. Консолідація на одному домені - це робота на вечір, і вона робить для безпеки клієнтів більше, ніж плакат про обізнаність.

Керування динамічними кодами

Це розділ, який більшість фінансових посібників з QR пропускає. Динамічний код - це редирект, який можна редагувати після друку, і саме тому він потребує контролю змін. Запитання, яке поставить аудитор або рецензент інциденту, - не "чи ви використовували QR-коди", а "хто міг змінити, куди вів цей, і чи можете ви показати, куди він вів у певну дату?"

Відповідають на це чотири засоби контролю.

Власність. Кожен код має іменовану команду й іменовану особу, записані під час створення. Спільні облікові записи це руйнують. Єдиний вхід (SSO) із провізіонінгом каталогу припиняє здатність колишнього працівника переспрямовувати код відділення в день його відходу. Модель провізіонінгу охоплює матеріал SCIM і SSO для маркетингових інструментів.

Розділення ролей. Не кожен, хто може створити код, повинен мати змогу змінювати ціль регульованого. В Elido є ролі Owner, Admin, Editor і Viewer, а на плані Business - власні ролі, тож ви можете дати кампанійній команді права редагування рекламних посилань, а коди точок обслуговування залишити за меншою групою.

Запис змін. Вам потрібна ціль на момент запуску, кожна подальша зміна, хто її зробив і коли. Elido зберігає історію кожного посилання на дашборді, а журнал аудиту робочого простору записує зміни учасників, ключів API та налаштувань, з експортом у CSV і кінцевою точкою API. Зверніть увагу на обмеження: платні плани зберігають 90 днів історії аудиту, а Free - 30, тож банк із довшим обов'язком зберігання має експортувати за графіком, а не покладатися на дашборд. Довідкова сторінка журналу аудиту перелічує, що записується, а що ні.

Виведення з обігу. Коли кампанія закінчується, код не зникає з паперу. Вирішіть під час створення, чи він переспрямовує на безпечну резервну сторінку, чи вимикається. Запишіть це.

Якщо ви хочете ці засоби контролю для кодів, які вже друкуєте, можете створити тестове посилання на безкоштовному плані і перевірити його історію змін, перш ніж братися за друкований тираж. Сторінки функцій QR-кодів і власних доменів показують, що доступно.

Що насправді кажуть правила

Я триматимуся того, що можу підтвердити джерелом. Багато вендорського контенту розмиває "рекомендується" і "вимагається".

PSD2. Стаття 97 вимагає сильної автентифікації клієнта, коли платник отримує доступ до платіжного рахунку онлайн, ініціює електронний платіж або робить щось віддалено, що несе ризик шахрайства. Текст є в інтерактивному зводі правил EBA. Для QR-кодів наслідок скромний. Сканування заповнює форму; автентифікація все одно відбувається в застосунку. Дизайн, де саме сканування запускає платіж, - це те, що варто поставити під сумнів.

GDPR. Два принципи кусають щодо даних сканувань. Обмеження зберігання (стаття 5(1)(e)) означає, що персональні дані зберігаються не довше, ніж потрібно, а безпека обробки (стаття 32) охоплює редирект і його журнали. Регламент не вказує кількості днів для журналів сканувань; зберігання даних кліків пояснює, як встановити й задокументувати його, а QR-коди та GDPR розповідає, що сканування насправді збирає. Посібник EDPB для МСП - читабельна відправна точка для боку підзвітності.

DORA. Закон про цифрову операційну стійкість (Регламент (ЄС) 2022/2554) застосовується до фінансових суб'єктів ЄС із січня 2025 року й зобов'язує їх керувати ризиками третіх сторін в ІКТ, зокрема вести реєстр договорів на ІКТ-послуги. Чи потрапляє постачальник QR і редиректів у сферу дії - питання до ваших команд з відповідності та закупівель. Ставте його до підписання договору, а не після, і починайте зі сторінки EBA про DORA.

Для чого я не зміг знайти першоджерела - це будь-яке правило, що вимагає QR-кодів, забороняє їх або встановлює термін зберігання саме для журналів сканувань QR. Зберігання для маркетингових комунікацій і обслуговування випливає з ваших власних зобов'язань щодо ведення записів, а не з правила, специфічного для QR. Якщо вендор каже інакше, попросіть номер статті.

Контрольний список запуску

Перш ніж банк, фінтех чи страховик друкуватиме наступний тираж:

• Один брендований домен, лише з HTTPS, для кожного коду, спрямованого на клієнтів.
• Платіжні коди окремо від кодів-посилань і протестовані в кількох банківських застосунках.
• Жодних персональних даних, номерів рахунків чи токенів у будь-якому URL.
• Іменований власник і рольові права редагування для кожного регульованого коду.
• Письмове правило виведення з обігу та термін зберігання журналів сканувань.
• Запланований експорт запису змін, якщо ваш обов'язок зберігання перевищує вікно дашборда.
• Розміщення із захистом від втручання та журнал перевірок для кодів на банкоматах і у відділеннях.
• Повідомлення клієнтам про те, чого легітимне сканування ніколи не попросить.

Читайте серію Cornerstone

Ця публікація входить до кластера індустрій. Cornerstone для друкованих процесів - QR-кампанія з нуля, а сторінка рішень для відповідності охоплює налаштування для регульованих галузей. Ціни на згадані вище плани є на сторінці цін.

Пов'язані публікації в блозі

• QR-код EPC: стандарт платіжного QR для SEPA
• Чи безпечні QR-коди? Квішинг і як лишатися захищеним
• Скорочувачі URL для фінтеху: KYC, відповідність, геоблокування
• QR-коди та GDPR: що збирає сканування і що ви винні
• Зберігання даних кліків: як довго тримати журнали аналітики
• Шахрайство з QR-кодами квитків на події: як запобігти скріншотам