Финтех архитектура: нещата, които не подлежат на договаряне

В повечето софтуер един бъг е инцидент. Във финтеха бъгът е задължение, което може вече да е струвало пари, без някой още да го е забелязал.

Финтех архитектурата има малък брой наистина недоговоряеми решения. Сгрешите ли ги, никакво по-късно инженерство не наваксва напълно — наследявате система, в която парите могат да са беззвучно грешни, а това е единственият режим на отказ, който финансов продукт не може да поеме.

1. Салдата се извеждат, никога не се пазят като истина

Най-честата и най-разрушителна грешка е променлива колона за салдо, която кодът обновява директно. Тя е удобна, бърза и невъзстановима: щом се отклони, няма как да се определи каква е трябвало да бъде.

Правилният модел е журнал със записи само за добавяне. Нищо никога не се обновява или трие; корекциите са нови компенсиращи записи. Салдото е сумата от записите — кеширано за производителност, но винаги възстановимо от журнала.

2. Всеки паричен път е идемпотентен

Мрежите повтарят заявки. Потребителите щракат два пъти. Платежните доставчици доставят уебхуци повече от веднъж — това е документирано поведение, а не граничен случай. Всяка операция, която движи пари, трябва да е безопасна при многократно изпълнение.

• Всяка парична операция носи ключ за идемпотентност, подаден от извикващия, уникален за логическото намерение
• Ключът се записва с ограничение за уникалност преди страничните ефекти, а не след тях
• Повторен ключ връща първоначалния резултат, вместо да върши работата отново
• Обработчиците на уебхуци записват суровия payload с ключ идентификатора на събитието на доставчика и едва после обработват — така повторна доставка се разпознава дори по средата на обработката

3. Парите са цели числа в минорни единици

Плаващата запетая не може да представи десетични дроби точно, затова аритметиката върху пари във float натрупва грешка. Пазете минорните единици като цели числа (или десетичен тип с фиксирана точност) и правете валутата явна при всяка сума — сума без валута е бъг, който чака първия международен клиент.

4. Равнението е функционалност, а не последваща мисъл

Приемете, че ще има разминаване между вашия журнал и платежния доставчик — ще се случи, чрез таймаути, частични откази и корекции от страна на доставчика. Въпросът е дали ще го засечете.

• Планирана задача, която сравнява вътрешното състояние със сетълмент данните на доставчика
• Аларма при разминаване, с определен отговорник и runbook
• Определен път за решаване — компенсиращи записи, никога тиха корекция
• Прочистване на заседнали състояния: транзакции в pending по-дълго, отколкото трябва

5. Изолация, и в двата смисъла

• Изолация на наематели — налагана на ниво данни, а не с надеждата, че всяка заявка съдържа правилния филтър
• Изолация на отказите — бавен доставчик не бива да изчерпва пула от заявки и да събаря несвързана функционалност
• Изолация на средите — никога тестови транзакции в продукционни журнали

6. Строете за одита, който рано или късно ще срещнете

Не. Той дава технически констатации в уговорения обхват. Правната оценка и формалната сертификация изискват съответните квалифицирани специалисти.

• Неизменна одитна следа кой какво и кога е направил — включително вътрешните административни действия
• Картовите данни никога да не докосват вашите сървъри, освен ако наистина възнамерявате да сте PCI-съвместими (използвайте hosted fields или hosted страница)
• Съхранение и изтриване на данни, които наистина могат да се изпълнят при поискване
• Контрол на достъпа, който подлежи на преглед — кой може да движи пари, кой го е одобрил

В обикновения софтуер оптимизирате за скорост на промяната. Във финтеха оптимизирате за способността по-късно да докажете точно какво се е случило и защо.

Петте въпроса към собствената ви система

1. Ако този уебхук пристигне два пъти, променя ли се нещо втория път?
2. Мога ли да възстановя салдото на който и да е клиент в който и да е минал момент само от журнала?
3. Бихме ли засекли разминаване с доставчика, или клиент би ни казал?
4. Може ли подправена заявка да прочете или премести парите на друг наемател?
5. Ако регулатор попита кой е одобрил ръчна корекция миналия март, бихме ли отговорили за минути?

Разделяйте приемане на транзакция и сетълмент

Платежните състояния трябва да обясняват закъснели и повторени събития. Проверявайте финансови записи и процедурата за корекции.

1. Използвайте точни десетични или цели минимални единици с валутни правила.
2. Свързвайте събития и записи без двойно отчитане на повторения.
3. Запазвайте оригиналите и следата на одобрените корекции.

• технически одит fintech →