Система обробки ACH-платежів для фінансової платформи

Про клієнта та його технологічні потреби

ACH — це фінансова мережа США, яка забезпечує безпечний електронний переказ коштів між банківськими рахунками у різних установах та підтримує зворотні платежі.

Наш клієнт — американська фінансова платформа, яка співпрацює з брокерами та синдикатами для видачі кредитів кінцевим споживачам, інтегруючись із банківськими API для дебетових і кредитних операцій. Платформа обробляє великий обсяг транзакцій і залучає зовнішніх учасників до процесу платежів. Через складну систему нарахування відсотків усім учасникам, значні обсяги даних та загальну складність управління фінансами, компанія потребувала рішення для автоматизації платежів.

Було прийнято рішення впровадити систему, яка підтримує платежі через ACH із використанням протоколу NACHA для обміну файлами та має окрему логіку розподілу коштів між клієнтами, брокерами й синдикатами.

Складність процесу кредитування

Існуюча фінансова архітектура клієнта передбачає багатоетапну перевірку з різними критеріями. Щоб процес працював без збоїв, необхідно налагодити прозору та безперебійну взаємодію між клієнтом, брокерами та синдикатами, з правильним і своєчасним управлінням відсотковими виплатами. Це створює як технічні, так і організаційні виклики:

• Складність багатостороннього фінансування з різних джерел (кожен платить окремо)

• Відмінності в графіках платежів для клієнтів, синдикатів і брокерів

• Складна структура комісій або відсотків з різними одержувачами

• Непередбачувані платіжні потоки (наприклад, платіж може бути повернено після того, як уже було виплачено відсотки, що потребує корекції в наступному циклі)

Як розробник програмного забезпечення, ми мали врахувати всі ці аспекти, щоби створити практичне рішення для автоматизації та оптимізації обробки ACH-платежів, забезпечивши точне, своєчасне та прозоре управління коштами для всіх сторін.

Виклики під час розробки

Клієнт надав лише загальні бізнес-вимоги: автоматизована система управління коштами для всіх учасників. NetLS повністю відповідала за проєктування, архітектуру та користувацький досвід системи. Основні труднощі, з якими ми зіткнулися під час створення ПЗ для роботи з ACH-файлами:

• Складна логіка: комісії, послідовність транзакцій, множинні ролі учасників

• Нестабільність банківських сервісів у США (затримки, відсутність злагодженої комунікації між відділами та установами)

• Коректне форматування NACHA-файлів. NACHA — це набір інструкцій, які активують пакет ACH-платежів при завантаженні у банківський портал. Файл має бути у форматі, що дозволяє сканувальному додатку коректно зчитати дані (наприклад, лише латиниця; при наявності кирилиці чи спецсимволів платіж повертається). До того ж, різні банки можуть вимагати варіації формату.

• Частина відхилених платежів обробляється вручну через обмеження на боці банку

• Строгий контроль відповідності критеріям, які визначають, які платежі можна проводити й коли

• Деякі транзакції виконуються поза межами платформи, але система все одно повинна моніторити, планувати та звітувати по всіх платежах — це ускладнює нарахування та розподіл виплат

• Висока відповідальність — система обробляє десятки мільйонів доларів щомісяця, що вимагає максимальної точності та стабільності

• Банки надсилають звітність по різних типах платежів в одному пакеті, тому система повинна чітко їх розрізняти — особливо враховуючи, що дебетові платежі вже реалізовані у продуктиві для всіх банків, з якими ми працювали. Ми мали гарантувати, що нові функції не вплинуть на наявну інфраструктуру.

Завдяки багаторічному досвіду в fintech-розробці та найкращим практикам Agile, наша команда успішно подолала всі ці виклики та перевершила очікування клієнта.

Що ми зробили

У нашому рішенні ми реалізували:

• Автоматизовані B2B ACH-платежі брокерам (виплати) та синдикатам (виплати й збори коштів). Спочатку — через Next-Day ACH, тепер — через Same-Day ACH

• Інтеграцію з кількома банками США через SFTP відповідно до політик безпеки (на on-prem або в Azure Cloud)

• Розподіл платежів за типом, банком і рахунком у окремі NACHA-файли

• Прозору звітність для бухгалтерії та кінцевих отримувачів

• Автоматичне або заплановане виконання платежів

• Обробку повернених транзакцій: автоматично або вручну. (Створено звіти по всіх очікуючих, непідтверджених або відхилених платежах з діями: підтвердити, змінити, повторно надіслати)

• Оптимізовані процеси на Azure Cloud дозволили знизити витрати та зменшити залежність від аналітиків, мінімізуючи людський фактор

Що в результаті

Наша платформа для обробки платежів:

• Дозволяє ініціювати платежі безпосередньо з внутрішнього порталу

• Перевіряє банківські реквізити перед надсиланням, щоб уникнути помилок. Навіть якщо одна транзакція некоректна, інші все одно будуть успішно проведені

• Забезпечує повну звітність по всіх типах платежів — очікуючих, виконаних, відхилених

• Автоматично або вручну обробляє повернення

• Відстежує походження й призначення кожного платежу (один учасник може ініціювати кілька транзакцій)

• Має кастомну адмін-панель для управління масовими ACH-платежами з кнопками для масової оплати або ручного редагування

• Реалізує підхід, заснований на ризиках ("ACH Alert", "ACH debit activity", "ACH credit transfers")

Як працює система

Система обробляє ACH Alert на початку робочого дня — він містить статус виконаних платежів (як дебетових, так і кредитних).

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

Деякі банки надсилають підтвердження у вигляді файлу з підсумковою сумою партії. Пакети створюються за допомогою бібліотеки NACHO (National Automated Clearing House Objects).

Підтвердження успішної обробки від банку не надходить. Єдине джерело такої інформації — return-файл, який зчитується зі сховища банку о 6:00 ранку. Він містить інформацію про невдалі платежі.

Пакети платежів відправляються вранці та ввечері окремими процесами для кредитів і дебетів.

Return-файли обробляє головний процес, який розподіляє їх між підпроцесами за типами платежів.

Система вважає, що платіж успішний, якщо його не повернули протягом 2 робочих днів (оскільки 98% повернень відбувається в цей період).

Повернення можливі до 5 робочих днів. Навіть якщо платіж уже позначено як успішний, він може бути пізніше змінений на повернутий.

Якщо платіж не було оброблено належним чином, він відображається у спеціальному alert-блоці в звітах. Є можливість вручну підтвердити або автоматично додати до наступного пакету.

Для автоматизації процесів використовуються Microsoft Azure Functions з таймерами.

Результати

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

• Enterprise-додаток на ASP.NET (бекенд — C#, фронтенд — JavaScript, CSS, Knockout.js)

• Azure DevOps — для CI/CD

• Webhooks, фонові задачі, бібліотека SignalR — для передачі даних і сповіщень

• Безпека — захищений SFTP із SSH, шифрування даних у MS SQL та Azure Blob

• Цілісність даних — MS SQL, Dapper + Entity Framework

• Стабільність — валідація на бекенді й фронтенді, контроль аномалій

• UX — Razor Views + JavaScript

• Підтримка всіх браузерів (навіть старих) через Knockout.js

• Автоматизоване створення NACHA-файлів через C# і SQL, SFTP, обробка повернень

• Мінімізація паперової роботи — завдяки підпису та автоматичній генерації платежів

• Продуктивність — оптимізований .NET-код, SQL Server, збережені процедури, T-SQL

• Актуальність — підтримка сучасних стандартів, складних транзакцій

• Прискорення обробки — Same-Day ACH за замовчуванням, автоперевірка, сповіщення

• Відповідність стандартам Open Banking (правові та безпекові вимоги)

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