Рішення · Фінансові послуги
Застосунок для фінансових послуг оцінюють за тим, що відбувається на його межах: що записується в журнал, що стається, коли клієнт просить повернути свої дані, що видно з переддоговірного інформування і що відбувається, коли запланована задача не запускається. Ми будуємо механіку; кредитна політика залишається за вами.
Вже збудованоПлатформа кредитування в продакшені, перевірювана зовні сьогодні: публічна частина — це статично скомпільований застосунок із 50 екранами, серед яких чотири калькулятори — кредит, відповідність, рефінансування, графік платежів — сторінки за типом кредиту, переддоговірна інформація та маршрут, через який клієнт запитує свої персональні дані; бізнес-частина — модульний backend на TypeScript із 16 модулями та 18 таблицями в схемі даних, серед яких контракт, платіж, журнал аудиту, запит щодо персональних даних, завантажений документ, щоденний знімок показників і запуск запланованого завдання. Карта сайту на продакшені перелічує 227 адрес, а румунські й російські маршрути обидва відповідають — перевірено мною 06.09.2026. Застереження, яке ми говоримо: доказ — із коду та публічних відповідей, а не з внутрішньої поведінки сервера — я не перевіряв, на якій версії працює продакшн, і не перевіряв, що всі 16 модулів активні на live.
Кредитній компанії не потрібен сайт. Їй потрібен повний ланцюг: запит надходить онлайн, проходить через потік ухвалення рішення, створює договір, генерує графік платежів і лишає слід в аудиті. Кожна відсутня ланка в ланцюгу перетворюється на людину, яка копіює дані з одного місця в інше, а у фінансових послугах кожне ручне копіювання — це і проблема відповідності, не лише часу.
Структура, яку ми будуємо, прямо відображає це в даних. У платформі, на яку ми посилаємося, схема має 18 таблиць, і їхній список говорить більше за будь-який архітектурний опис: запит, договір, платіж, одноразовий код, сесія, запит на дзвінок, шаблон сповіщення, журнал сповіщень, щоденний знімок показників, запуск запланованої задачі, стаття, перенаправлення адреси, налаштування видимості, внутрішня нотатка, журнал аудиту, завантажений документ, запит щодо персональних даних. Backend поділено на 16 модулів, серед яких один присвячений виключно правам суб’єкта даних.
Публічна частина — не декорація: чотири калькулятори — кредит, придатність, рефінансування та графік платежів — плюс окремі сторінки за типом кредиту і переддоговірне інформування. У споживчому кредитуванні переддоговірне інформування — не іміджева сторінка: це обов’язок показати умови до того, як людина зобов’яжеться. Ми трактуємо це як вимогу продукту, а не як юридичний текст, приклеєний наприкінці. Румунські маршрути залишаються без префікса, а російські йдуть окремим сегментом, з канонічними мітками та альтернативами, згенерованими з мови активного маршруту.
І межа, яку треба сказати до договору: потік ухвалення рішень щодо запитів — правила, пороги, затвердження — за вами. Ми будуємо механіку, через яку запит рухається, документується і стає договором. Ми не пишемо кредитну політику і не беремо на себе оцінювання заявника; це юридично значущі рішення, які належать уповноваженій установі.
Що входить
Запит надходить онлайн і живе як окрема сутність, зі видимим станом і екраном відстеження для клієнта. Завантажені документи мають свою таблицю, договір — свою, платіж — свою. Різниця від форми, яка надсилає e-mail, у тому, що через три місяці можна відповісти з даних на запитання «що сталося із запитом від 12 березня».
Договір і графік не складаються вручну в окремому документі: вони виходять із даних схваленого запиту. Це єдиний варіант, за якого цифра в договорі та цифра в графіку не можуть відрізнятися, а клієнт, який телефонує з документом у руці, говорить про те саме, що й оператор, який дивиться в систему.
Кредит, придатність, рефінансування і графік платежів — окремі публічні екрани без автентифікації. У споживчому кредитуванні калькулятор — це перша реальна взаємодія: людина хоче побачити платіж до того, як говорити з кимось. А рефінансування — це окремий калькулятор, не той самий, що для кредиту, не з іншими мітками.
Власна сторінка, а не абзац у підвалі. Причина практична: якщо інформування не на тому маршруті, яким людина йде перед тим, як підписати, воно не виконує свою роботу ні для неї, ні для установи. Текст належить вам і вашим юристам; ми будуємо місце, момент і простежуваність.
Існує публічна сторінка, через яку клієнт запитує свої персональні дані, окремий модуль backend і екран адміністрування для отриманих запитів, а також таблиця, у якій вони зберігаються. Практичний наслідок: законний строк відповіді можна дотримати без того, щоб хтось відкривав базу даних вручну — і можна буде довести, через рік, що його було дотримано.
Журнал аудиту — це окрема таблиця, відмінна від внутрішніх нотаток операторів. Розділення важливе під час перевірки: одне — технічний облік того, що сталося, інше — те, що колега написав про справу. Змішані, перше стає нечитабельним, а друге — документом.
Існує таблиця для запусків запланованих завдань і таблиця для щоденних знімків показників. На фінансовій платформі завдання, яке не запускалося три ночі поспіль, — серйозніша проблема, ніж упала сторінка: цього не видно зовні, але воно змінює цифри. Тому запуск записується, а не передбачається.
Румунські маршрути залишаються без префікса, російські йдуть окремим сегментом, з канонічними та альтернативними мітками, згенерованими з мови активного маршруту. На карті сайту в продакшені є 227 адрес. Для кредитної компанії в Республіці Молдова російська частина — не переклад із ввічливості, а половина заявників.
Перевірки перед публікацією, міграції бази даних, виконані окремою командою в продакшені, генерація секретів, резервна копія та відновлення бази — усе як скрипти в репозиторії, а не як кроки в документі. У системі, що зберігає контракти та платежі, «відновлення» має бути командою, яку ви вже пробували, а не наміром.
Traseul
Що означає подана заявка, схвалена заявка, отриманий платіж; що відбувається із заявкою, на яку не відповіли; що закривається, коли зовнішній сервіс не відповідає. Ми постачаємо документ із словником та інваріантами, тому що на фінансовій платформі термін, ужитий у двох значеннях, пізніше стає двома різними цифрами в двох звітах.
Журнал аудиту та облік документів не додаються наприкінці; вони є частиною першої версії, що працює. Ми постачаємо повний потік від заявки до контракту, з його слідом, на тестових даних — не екрани, які добре виглядають над порожньою базою.
Публічні екрани, калькулятори, сторінки за типом кредиту та переддоговірне інформування, з румунськими адресами без префікса і російськими на окремому сегменті, з правильними канонічними мітками. Ми постачаємо карту сайту, згенеровану з даних, і перевірку, що обидві версії відповідають.
Перевірка перед публікацією, міграції в продакшені окремою командою, генерація секретів, резервна копія та відновлення — перевірені, а не лише записані. Ми передаємо репозиторій, документ із введення в експлуатацію та доступи. Відновлення бази демонструється під час здачі, один раз, у вашій присутності.
Дані
Правила відрізняються від однієї галузі до іншої. Це ті, що застосовуються у фінансових послугах.
Випадок
Ситуація
Початкова вимога в проєкті кредитування звучить майже завжди однаково: «сайт із формою заявки». Проблема з’являється на другому місяці, коли хтось питає, де договір, хто змінив досьє і як ми відповідаємо на запит доступу до персональних даних у встановлений законом строк.
Що ми збудували
Ми побудували платформу в двох половинах, в одному й тому самому репозиторії. Публічна частина — це статично скомпільований застосунок із 50 екранами: чотири калькулятори — кредиту, відповідності, рефінансування, графіка платежів — сторінки за типом кредиту, переддоговірна інформація, відстеження стану заявки та сторінка, через яку клієнт запитує свої персональні дані. Бізнес-частина — це модульний backend на TypeScript, із 16 модулями — серед яких автентифікація, права за ролями, потік заявок, документи, платежі, сповіщення, заплановані завдання та один, присвячений правам суб’єкта даних — поверх схеми з 18 таблицями: заявка, договір, платіж, одноразовий код, сесія, завантажений документ, журнал аудиту, запит щодо персональних даних, запуск запланованого завдання, щоденний знімок показників і решта.
Що вийшло
Ланцюг повний: заявка надходить, проходить, породжує договір і графік, а кожен крок залишає слід. Запити щодо персональних даних мають власний маршрут, з екраном адміністрування, тож законний строк можна дотримати й довести. Публічну частину можна перевірити ззовні: 227 адрес у мапі сайту, з обома живими мовними версіями.
Чого цей випадок не каже
Доказ — у коді та публічних відповідях, а не у внутрішній поведінці сервера: ми не перевіряли, на якій версії працює production, і чи всі 16 модулів активні на live. Потік ухвалення рішень щодо заявок — правила, пороги, схвалення — належить клієнту; ми побудували механіку, а не кредитну політику.
Питання
Ви. Правила, пороги та схвалення — це політика уповноваженої установи, а не постачальника програмного забезпечення. Ми будуємо механіку, через яку заявка проходить, документується, стає договором і графіком платежів, і залишає слід. Постачальник, який бере на себе рішення щодо кредиту, продає те, на що не має права.
Існує публічна сторінка, через яку він це просить, окремий backend-модуль, екран адміністрування та таблиця, у якій ця заявка живе. Тож можна відповісти в строк і потім це довести. Що не є технічним рішенням: що можна видалити і що треба зберегти відповідно до фінансового законодавства — це встановлюється з вашими юристами, до впровадження.
Із даних схваленої заявки, разом із графіком платежів — обидва з одного джерела, щоб вони не могли відрізнятися. Що залишається вашим, це зміст договору та його умови. Договір, складений вручну в окремому документі, — це класичне місце, де з’являються дві різні цифри для того самого кредиту.
Тому що в споживчому кредитуванні інформація має бути на шляху, яким іде людина перед тим, як зобов’язатися, а не в підвалі. Ми розглядаємо її як частину продукту: місце, момент і простежуваність — наші, текст — ваших юристів.
Щонайменше стільки, скільки відповідає різним рішенням. На платформі, яку ми цитуємо, їх чотири — кредит, придатність, рефінансування, графік платежів — тому що рефінансування не є тим самим обчисленням, що й новий кредит, а графік відповідає на інше запитання, ніж ставка. Один калькулятор із багатьма полями важче використовувати, ніж чотири прості.
Ні, і це правило, а не перевага: ми будуємо й тестуємо на тестових даних. Доступ до реальних даних, коли він потрібен, надається визначеним особам, на встановлений період і з слідом у журналі. У фінансовій системі «мені треба було подивитися в продакшені» — це речення, яке має з’явитися в журналі, а не в розмові.
Це видно, тому що виконання записуються в окрему таблицю, поряд із щоденними знімками показників. Це важливо саме тому, що задача, яка не запустилася, не дає жодного видимого зовнішнього симптому — сайт відповідає, екрани виглядають добре, але цифри більше не рухаються.
Жодної цифри обсягу, ставки, кількості заявок чи клієнтів, навіть якщо вона публічно показана на його сайті — тому що це його твердження, а не наше вимірювання. Що ми можемо показати — це структуру: скільки модулів, які таблиці, які публічні екрани, що перевіряється під час публікації. Те саме правило застосовуватиметься і до вашої роботи.
Публічну частину можна перевірити зараз: карта сайту має 227 адрес, а румунська та російська версії одного калькулятора обидві відповідають. Backend-частина читається з коду — модулі та схема даних — а не з поведінки сервера: ми не перевіряли, на якій версії працює продакшен, і не перевіряли, що всі модулі активні на live, і ми воліємо написати це, ніж залишити протилежне враження.
Розкажіть про свій процес. Разом визначимо, що варто збудувати, що можна підключити і як перевіримо результат.