BANKING TRACKER

The Enable Banking documentation lied three times, and each lie was only exposed by the live bank. First: the API takes lowercase snake_case (valid_until, redirect_url) where the docs suggested camelCase — and the /auth response returns a url field, not the documented authorizationUri, so the client reads all variants defensively. Second: with continuation_key pagination the bank returns 422 unless you repeat the SAME date_from parameters — the first version sent the parameters alternately and subsequent pages failed. Third: Pekao rejects a request for 90 days of history with a 400 — solved with adaptive descent through 90/60/30/14/7 days until the bank accepts the range. The regulatory cherry on top: PSD2 lets banks cap unattended data pulls at 4 per day, which auto-sync exhausted by morning — passing the user's real IP and User-Agent as PSU headers legally reclassifies the request as customer-initiated and lifts the limit, with the IP regex-validated before it ever reaches the bank.

The first PIN login had a 'lockout after 4 attempts' and looked sensible — until I ran a formal security audit on my own code (20 findings across four severity levels). The audit exposed two serious defects at once: the attempt counter was non-atomic — SELECT, +1 in JavaScript, UPDATE — so N parallel requests read the same state and wrote back 1, letting a race bypass the lockout and brute-force the whole 10,000-PIN space in batches; and the 'correct' permanent lockout turned out worse than the attack, because anyone sending 4 wrong PINs turns the app into a brick requiring a redeploy (self-DoS). The final model: the counter incremented atomically in the database, constant-time PIN comparison (timingSafeEqual), and a growing 5 s → 5 min backoff instead of a lockout — an attacker waits exponentially, the owner briefly after a typo. Every audit finding has an id cited in the fixes, so the finding→fix trail is fully auditable.

Automatic categorization from day one would have been either dumb or expensive — instead I designed a 'human → rules → AI' path. At first I sign transactions by hand, but every correction creates a rule ('Żabka → Daily'), so known shops quickly clear themselves; AI enters last and signs using the learned rules, with only exceptions reaching me. The system earns trust gradually — at exactly the pace it deserves it.

An account balance lies: it ignores the rent leaving next week, unpaid subscriptions, and money earmarked for goals. I split money into three layers — real accounts (bank balances), budget envelopes (spending control) and goals/reserves (untouchable) — and 'truly available' is balances minus obligations and earmarked funds. The one number I can trust at the checkout turned out to be the hardest data model in the whole app.