Український розробник Владислав Бражнік представив застосунок obleek — трекер витрат, який автоматично зчитує пуш-сповіщення від банківських застосунків і створює транзакції. Ключова особливість: obleek не потребує прямого доступу до банківських рахунків і не використовує Open Banking API. Це вирішує болючу проблему ручного введення витрат, з якою стикаються багато українців.
Ідея obleek виникла з практичної потреби. Більшість банківських застосунків в Україні надсилають пуш-повідомлення після кожної транзакції, але не дають зручних інструментів для категоризації та аналізу витрат. Користувачам доводиться або вручну переносити дані в таблиці, або миритися з обмеженою аналітикою від банку. obleek пропонує автоматизацію: застосунок перехоплює пуші, розпізнає суму, merchant та категорію, після чого формує структурований запис. Це схоже на те, як працюють популярні західні сервіси на кшталт Mint або YNAB, але без інтеграції через API.
Відмова від Open Banking API — свідомий крок. В Україні Open Banking поки що не набув масового поширення: не всі банки підтримують стандартизовані інтерфейси, а користувачі насторожено ставляться до надання стороннім застосункам доступу до рахунків. obleek використовує інший підхід — аналіз локальних пуш-сповіщень. Це означає, що застосунок працює на пристрої користувача, не передаючи чутливі фінансові дані на зовнішні сервери. Така архітектура знижує ризики витоку даних і робить продукт привабливішим для тих, хто не довіряє хмарним сервісам.
Для українського ринку це особливо актуально. За даними НБУ, кількість безготівкових операцій зростає щороку, а пуш-повідомлення від банків є звичним явищем для більшості клієнтів. Водночас культура фінансового планування в Україні лише формується. Застосунки для обліку витрат — переважно або занадто складні (потребують ручного введення кожної витрати), або залежать від банківських API, які не завжди доступні. obleek пропонує компроміс: автоматизація без інтеграції з банком.
Технічно застосунок, ймовірно, використовує дозволи на читання сповіщень в Android або iOS. Це стандартна практика для подібних трекерів. Однак залишається питання точності розпізнавання: пуші від різних банків мають різний формат, і не всі містять повну інформацію про merchant. Розробник не розкриває деталей про алгоритми парсингу, але обіцяє, що obleek навчається на типових шаблонах. Згодом застосунок може пропонувати користувачам коригувати категорії вручну, якщо автоматика помиляється.
Конкурентне середовище в Україні включає як локальні розробки (наприклад, «Витрати» або «Гроші»), так і міжнародні застосунки (Money Lover, CoinKeeper). Більшість із них вимагають ручного введення або підключення до банків через API. obleek виграє за рахунок автоматизації та локальної обробки даних. Втім, масштабування на iOS може бути складнішим через обмеження Apple щодо доступу до сповіщень інших застосунків. Якщо obleek вийде на iOS, це стане значною перевагою.
Для українських продуктових команд кейс obleek — приклад того, як локальна проблема (незручність банківських застосунків) стає основою для MVP без залучення інвестицій. Розробник не чекав, поки Open Banking стане стандартом, а знайшов обхідний шлях. Це урок для стартапів: іноді варто будувати продукт на наявних даних, а не чекати на інфраструктуру. Якщо obleek зможе забезпечити точність і зручність, він має шанс зайняти нішу персональних фінансів в Україні.
2
