Yusr
Yusr - платформа рассрочки для рынка автосервисов ОАЭ. Автосервис подаёт заявку за клиента, а платформа проверяет личность, оценивает кредитный риск и формирует график платежей.
Контекст
У клиента, который приходит в автосервис, решение по рассрочке должно появиться примерно за минуту - без участия человека. Пока он ждёт у стойки, система должна успеть проверить личность, признаки мошенничества и кредитный риск.
Весь продукт работал на no-code-стеке. Интерфейс был в Bubble, поэтому логика решений, интеграции и работа с деньгами должны были оставаться в базе данных: там их можно проверить, а не искать по разросшимся воркфлоу.
Роль и объём работ
За что отвечала я
Я отвечала за бэкенд-логику в Supabase (PL/pgSQL), все интеграции с внешними сервисами, движок андеррайтинга, который превращает входящие данные в решение, модель безопасности и перенос в банковское ядро. Сама кредитная модель - работа аналитиков заказчика; моё - всё, что её кормит, и всё, что происходит после её ответа.
Кто ещё работал
Кросс-функциональная команда: второй разработчик, QA, дизайнер, PM, аналитик и DevOps.
Срок
С октября 2025 года по август 2026 года. Проект завершился, когда заказчик перерос возможности разработки без кода: требования комплаенса диктовали необходимость собственного стека, и продукт перевели на код.
Ход работы
01 · Движок решений
Всё начинается с триггера на PL/pgSQL: как только завершается проверка личности, он собирает данные из пяти источников - KYC, кредитного бюро, отпечатка устройства, верификации через WhatsApp и истории займов самого заявителя. Затем складывает их в один пакет и передаёт в скоринговый сервис заказчика через AWS Lambda. Lambda здесь - промежуточный узел: Supabase работает на RDS, а RDS сам не умеет отправлять исходящие HTTP-запросы.
Вернувшийся ответ сохраняется, и функция андеррайтинга взвешивает его вместе с шестью другими показателями, прежде чем принять решение. Высокий балл сам по себе не означает одобрения: если заявка не проходит более раннее правило, до скоринга она вообще не доходит.
Дедупликация личности сравнивает присланное имя с именем в Emirates ID по расстоянию Левенштейна. Реальные имена приходят с опечатками, переставленными частями или обрезанными банком.
02 · Когда балла недостаточно
Некоторые заявители возвращаются из скоринга с вердиктом «требует дополнительной проверки». Платформа предлагает им подключить банковский счёт через Lean, провайдера Open Banking. Его виджет работает как JavaScript SDK, поэтому внутри Bubble запускается через вставку скрипта.
Моя часть начинается после нажатия «Подключить»: забрать данные заявителя, счета и транзакции за полгода по каждому счёту, сохранить их и пройти циклами, прежде чем функция на PL/pgSQL вынесет окончательное решение.
Самым сложным оказались не данные. Виджет молча отказывался открываться в Safari и во встроенном браузере WhatsApp, где ограничены оверлеи и куки. Это удалось понять только после того, как мы попросили клиентов записать экран.
03 · Утечка данных: не латать, а устранять причину
В июне выяснилось, что сторонний плагин Bubble по-разному вёл себя на демо и на проде: мерчанты видели данные друг друга. Быстрое решение - залатать запрос. Вместо этого я заменила плагин SQL-функцией с
SECURITY DEFINER , которая фильтрует по компании на стороне сервера. До неё ошибка в клиентском коде уже не дотянется.
На том же принципе построена остальная модель безопасности: политики row-level security на каждой таблице, с отдельными правилами для мерчанта, клиента и админа.
04 · Переезд портфеля займов
Заказчик переходил на банковское ядро, и весь действующий портфель должен был переехать вместе с ним, не останавливая выдачу. Я собрала ETL на Python: он переводил пять выгрузок из Supabase в схему ядра и разбирался с битыми CSV, расхождениями в округлении и дублями клиентов.
Сначала демо, потом холостой прогон на 35 партиях, затем продакшен - и всё под набором из девяти SQL-проверок. Все остатки сошлись: 1395 займов, 1294 клиента, 7496 счетов, 5634 платежа.
После переезда пришлось менять и андеррайтинг. Теперь решение в трёх местах обращается к банковскому ядру напрямую - за действующими займами, просрочкой и кредитными лимитами - вместо того чтобы доверять локальной копии, которая могла устареть.
Результат
258
действующих мерчантов: рост с 10 за семь месяцев
1395
займов перенесено, расхождений в остатках нет
~1000
заявок в месяц проходило через эту логику
Мы с Юлей около года вместе строили YUSR BNPL - не просто MVP, а полноценную финтех-систему: сайт, личный кабинет клиента, кабинет мерчанта и админку. Юля из тех, кто просто берёт и делает. Если что-то сломано или непонятно, она будет копать, пока не разберётся, почему так, а не просто подлатает симптом.
Юля - один из самых надёжных людей, которым я поручал задачи. Юле можно поручить задачу и дальше о ней не думать: не нужно ни микроменеджмента, ни постоянных проверок. Она задаёт правильные вопросы в начале, остальное разбирает сама, и за качество реализации можно не переживать.
Больше всего мне запомнилось, как она работала с ограничениями Bubble. Строить настолько сложную систему на no-code-инструменте - значит постоянно упираться в стены. И Юля раз за разом находила рабочий обход, вместо того чтобы развести руками и сказать, что это невозможно. С ней просто приятно работать: она ясно объясняет и на неё можно положиться.
В итоге компания выросла, из-за требований комплаенса понадобился собственный стек, и мы ушли с Bubble. С этим переездом Юля тоже помогала. Я с радостью поработал бы с ней снова и рекомендую без всяких оговорок.