BANKING TRACKER

Dokumentacja Enable Banking kłamała trzykrotnie, a każde kłamstwo odkrywał dopiero żywy bank. Po pierwsze: API przyjmuje snake_case małymi literami (valid_until, redirect_url), gdy dokumentacja sugerowała camelCase — a odpowiedź /auth zwraca pole url, nie authorizationUri z docs, więc klient czyta defensywnie wszystkie warianty. Po drugie: przy paginacji continuation_key bank zwraca 422, jeśli nie powtórzy się TYCH SAMYCH parametrów date_from — pierwsza wersja wysyłała parametry alternatywnie i kolejne strony padały. Po trzecie: Pekao odrzuca żądanie 90 dni historii błędem 400 — rozwiązałem to adaptacyjnym schodzeniem 90/60/30/14/7 dni, aż bank zaakceptuje zakres. Wisienka regulacyjna: PSD2 pozwala limitować nieinicjowane przez klienta pobrania do 4 dziennie, co auto-sync wyczerpywał od rana — przekazanie realnego IP i User-Agenta użytkownika jako nagłówków PSU legalnie zmienia klasyfikację żądania na inicjowane przez klienta i znosi limit, a IP jest walidowane regexem, zanim poleci do banku.

Pierwsza wersja logowania PIN-em miała „blokadę po 4 próbach” i wyglądała rozsądnie — dopóki nie przeprowadziłem na własnym kodzie formalnego audytu bezpieczeństwa (20 findingów w czterech poziomach). Audyt wykrył dwa poważne defekty naraz: licznik prób był nieatomowy — SELECT, +1 w JavaScripcie, UPDATE — więc N równoległych żądań czytało ten sam stan i zapisywało 1, co pozwalało wyścigiem obejść lockout i brute-force'ować całą przestrzeń 10 000 PIN-ów partiami; a „poprawna” trwała blokada okazała się gorsza od ataku, bo ktokolwiek wyśle 4 błędne PIN-y, zamienia aplikację w cegłę wymagającą redeployu (self-DoS). Model docelowy: inkrementacja licznika atomowo po stronie bazy, porównanie PIN-u w czasie stałym (timingSafeEqual) i rosnący backoff 5 s → 5 min zamiast blokady — atakujący czeka wykładniczo, właściciel po pomyłce chwilę. Każdy finding audytu ma id cytowane w naprawach, więc trasa finding→fix jest w pełni audytowalna.

Automatyczna kategoryzacja od pierwszego dnia byłaby albo głupia, albo droga — zamiast tego zaprojektowałem drogę „człowiek → reguły → AI”. Najpierw podpisuję transakcje ręcznie, ale każda korekta tworzy regułę („Żabka → Codzienne”), więc znane sklepy szybko schodzą same; AI wchodzi na końcu i podpisuje według wyuczonych reguł, a do mnie trafiają tylko wyjątki. System zdobywa zaufanie stopniowo — dokładnie w tempie, w jakim na nie zapracował.

Saldo konta kłamie: nie uwzględnia czynszu, który zejdzie za tydzień, niezapłaconych subskrypcji ani pieniędzy zaklepanych na cele. Rozdzieliłem pieniądze na trzy warstwy — konta realne (salda z banku), koperty budżetowe (kontrola wydatków) i cele/rezerwy (nietykalne) — a „naprawdę dostępne” to salda minus zobowiązania i środki celowe. Jedna liczba, której mogę zaufać przy kasie, okazała się najtrudniejszym modelem danych w całej aplikacji.