Fintech-architectuur: waarover niet te onderhandelen valt

In de meeste software is een bug een incident. In fintech is een bug een verplichting die mogelijk al geld heeft gekost zonder dat iemand het gemerkt heeft.

Fintech-architectuur kent een klein aantal werkelijk niet-onderhandelbare beslissingen. Sla je die mis, dan haalt geen enkele latere engineering dat volledig in — je erft een systeem waarin geld stilletjes verkeerd kan zijn, en dat is de enige faalwijze die een financieel product niet kan opvangen.

1. Saldi worden afgeleid, nooit opgeslagen als waarheid

De veruit meest gemaakte en meest schadelijke fout is een muteerbare saldokolom die code rechtstreeks bijwerkt. Dat is handig, snel en onherstelbaar: als hij afdrijft, valt niet meer vast te stellen wat hij had moeten zijn.

Het juiste model is een append-only journaal van boekingen. Er wordt nooit iets bijgewerkt of verwijderd; correcties zijn nieuwe tegenboekingen. Het saldo is de som van de boekingen, gecachet voor performance maar altijd reconstrueerbaar uit het journaal.

2. Elk geldpad is idempotent

Netwerken herhalen. Gebruikers dubbelklikken. Betaalproviders leveren webhooks meer dan eens af — dat is gedocumenteerd gedrag, geen randgeval. Elke operatie die geld beweegt moet veilig herhaald uitgevoerd kunnen worden.

• Elke geldoperatie draagt een door de aanroeper geleverde idempotency key, uniek per logische intentie
• De sleutel wordt met een uniciteitsconstraint opgeslagen vóór de bijeffecten, niet erna
• Een herhaalde sleutel geeft het oorspronkelijke resultaat terug in plaats van het werk opnieuw te doen
• Webhook-handlers slaan de ruwe payload op met de event-id van de provider als sleutel en verwerken daarna — zo wordt een herlevering ook midden in de verwerking herkend

3. Geld zijn gehele getallen in minor units

Floating point kan decimale breuken niet exact weergeven, dus rekenen met float-geld stapelt fouten op. Sla minor units op als gehele getallen (of een decimaal type met vaste precisie) en maak de valuta expliciet bij elk bedrag — een bedrag zonder valuta is een bug die op de eerste internationale klant wacht.

4. Reconciliatie is een feature, geen bijgedachte

Ga uit van afwijking tussen je grootboek en de betaalprovider — die komt er, door timeouts, gedeeltelijke storingen en correcties aan providerzijde. De vraag is of je hem detecteert.

• Een geplande job die de interne staat vergelijkt met de settlementdata van de provider
• Alerting bij discrepantie, met een aangewezen eigenaar en een runbook
• Een gedefinieerd oplospad — tegenboekingen, nooit stille correctie
• Sweeps op vastgelopen toestanden: transacties die langer in pending staan dan zou moeten

5. Isolatie, in beide betekenissen

• Tenantisolatie — afgedwongen in de datalaag, niet door te hopen dat elke query het juiste filter bevat
• Faalisolatie — een trage provider mag de requestpool niet uitputten en ongerelateerde functionaliteit platleggen
• Omgevingsisolatie — nooit testtransacties in productiegrootboeken

6. Bouw voor de audit die je uiteindelijk krijgt

Nee. De audit levert technische bevindingen binnen de afgesproken scope. Juridische beoordeling en formele certificering vragen de daarvoor bevoegde beoordelaars.

• Een onveranderlijk audittrail van wie wat wanneer deed — inclusief interne adminacties
• Kaartgegevens die je servers nooit raken, tenzij je werkelijk PCI-compliant wilt zijn (gebruik hosted fields of een hosted page)
• Bewaartermijnen en verwijdering die op verzoek daadwerkelijk uitvoerbaar zijn
• Toegangscontrole die te reviewen is — wie geld mag verplaatsen, wie het goedkeurde

In gewone software optimaliseer je op snelheid van verandering. In fintech optimaliseer je op het vermogen om later precies te bewijzen wat er gebeurde en waarom.

De vijf vragen aan je eigen systeem

1. Als deze webhook twee keer binnenkomt, verandert er dan iets de tweede keer?
2. Kan ik het saldo van elke klant op elk moment in het verleden alleen uit het grootboek reconstrueren?
3. Zouden wij een afwijking met de provider opmerken, of zou een klant het ons vertellen?
4. Kan een vervalst verzoek het geld van een andere tenant lezen of verplaatsen?
5. Als een toezichthouder vroeg wie afgelopen maart een handmatige correctie goedkeurde, konden we dat dan binnen minuten beantwoorden?

Scheid transactieacceptatie van afwikkeling

Betaalstatussen moeten late en herhaalde gebeurtenissen kunnen verklaren. Controleer financiële records en het correctieproces samen.

1. Gebruik exacte decimalen of gehele ondereenheden met valutaregels.
2. Koppel gebeurtenissen aan boekingen zonder herhalingen dubbel te verwerken.
3. Bewaar oorspronkelijke records en traceer goedgekeurde correcties.

• fintech technische audit →