Architektura fintech: rzeczy nie do negocjacji

W większości oprogramowania błąd to incydent. W fintechu błąd to zobowiązanie, które być może już kosztowało pieniądze, czego nikt jeszcze nie zauważył.

Architektura fintech ma niewielką liczbę decyzji naprawdę nie do negocjacji. Pomyl się w nich, a żadna późniejsza inżynieria w pełni tego nie odrobi — dziedziczysz system, w którym pieniądze mogą być po cichu błędne, a to jedyny tryb awarii, którego produkt finansowy nie zniesie.

1. Salda są wyprowadzane, nigdy przechowywane jako prawda

Najczęstszym i najbardziej niszczącym błędem jest zmienialna kolumna salda, którą kod aktualizuje wprost. Jest wygodna, szybka i nieodwracalna: gdy zacznie odjeżdżać, nie ma jak ustalić, ile powinna wynosić.

Poprawnym modelem jest dziennik zapisów tylko-do-dopisywania. Nic nigdy nie jest aktualizowane ani usuwane; korekty to nowe zapisy kompensujące. Saldo to suma zapisów — cache'owana dla wydajności, ale zawsze odtwarzalna z dziennika.

2. Każda ścieżka pieniędzy jest idempotentna

Sieci ponawiają. Użytkownicy klikają dwa razy. Dostawcy płatności dostarczają webhooki więcej niż raz — to udokumentowane zachowanie, nie przypadek brzegowy. Każda operacja przesuwająca pieniądze musi być bezpieczna przy wielokrotnym wykonaniu.

• Każda operacja pieniężna niesie klucz idempotencji podany przez wywołującego, unikalny dla logicznej intencji
• Klucz jest zapisywany z ograniczeniem unikalności przed efektami ubocznymi, a nie po nich
• Powtórzony klucz zwraca pierwotny wynik, zamiast wykonywać pracę ponownie
• Handlery webhooków zapisują surowy payload kluczowany identyfikatorem zdarzenia dostawcy, a dopiero potem przetwarzają — dzięki czemu ponowne doręczenie jest rozpoznawane nawet w trakcie przetwarzania

3. Pieniądze to liczby całkowite w jednostkach podrzędnych

Liczby zmiennoprzecinkowe nie reprezentują ułamków dziesiętnych dokładnie, więc arytmetyka na pieniądzach we float kumuluje błąd. Przechowuj jednostki podrzędne jako liczby całkowite (albo typ dziesiętny o stałej precyzji) i uczyń walutę jawną przy każdej kwocie — kwota bez waluty to błąd czekający na pierwszego klienta zagranicznego.

4. Rekoncyliacja jest funkcją, a nie refleksją po fakcie

Zakładaj rozbieżność między twoją księgą a dostawcą płatności — wystąpi, przez timeouty, awarie częściowe i korekty po stronie dostawcy. Pytanie brzmi, czy ją wykryjesz.

• Zaplanowane zadanie porównujące stan wewnętrzny z danymi rozliczeniowymi dostawcy
• Alert przy rozbieżności, z wyznaczonym właścicielem i runbookiem
• Zdefiniowana ścieżka rozwiązania — zapisy kompensujące, nigdy ciche korekty
• Przeglądy zawieszonych stanów: transakcje w stanie pending dłużej, niż powinny

5. Izolacja, w obu znaczeniach

• Izolacja najemców — egzekwowana w warstwie danych, a nie w nadziei, że każde zapytanie zawiera właściwy filtr
• Izolacja awarii — wolny dostawca nie może wyczerpać puli żądań i położyć niepowiązanej funkcjonalności
• Izolacja środowisk — nigdy transakcji testowych w księgach produkcyjnych

6. Buduj pod audyt, który w końcu nadejdzie

Nie. Dostarcza ustaleń technicznych w uzgodnionym zakresie. Interpretacja prawna i formalna certyfikacja wymagają odpowiednich uprawnionych specjalistów.

• Niezmienny ślad audytowy, kto co i kiedy zrobił — łącznie z wewnętrznymi działaniami administracyjnymi
• Dane kart nigdy nie dotykają twoich serwerów, chyba że naprawdę zamierzasz być zgodny z PCI (użyj hostowanych pól albo hostowanej strony)
• Retencja i usuwanie danych, które da się faktycznie wykonać na żądanie
• Kontrola dostępu, którą da się przejrzeć — kto może przesuwać pieniądze, kto to zatwierdził

W zwykłym oprogramowaniu optymalizujesz szybkość zmiany. W fintechu optymalizujesz zdolność udowodnienia później, co dokładnie się stało i dlaczego.

Pięć pytań do własnego systemu

1. Jeśli ten webhook przyjdzie dwa razy, czy za drugim razem cokolwiek się zmieni?
2. Czy potrafię odtworzyć saldo dowolnego klienta w dowolnym momencie z samej księgi?
3. Czy wykrylibyśmy rozbieżność z dostawcą, czy powiedziałby nam o niej klient?
4. Czy spreparowane żądanie może odczytać albo przesunąć pieniądze innego najemcy?
5. Gdyby regulator zapytał, kto zatwierdził ręczną korektę w zeszłym marcu, czy odpowiedzielibyśmy w kilka minut?

Oddziel przyjęcie transakcji od rozliczenia

Stany płatności muszą wyjaśniać spóźnione i ponowione zdarzenia. Sprawdź zapisy finansowe wraz z procesem korekt.

1. Używaj dokładnych liczb dziesiętnych lub całkowitych jednostek z regułami walut.
2. Powiąż zdarzenia i zapisy bez podwójnego księgowania ponowień.
3. Zachowaj oryginały i ślad zatwierdzonych korekt.

• audyt techniczny fintech →