Industry

Fintech

Money systems fail differently from other software. A bug in a booking system produces a bad booking. A bug in a ledger produces a number that is wrong, propagates silently, and is discovered by an accountant months later when the history needed to explain it no longer exists.

What we build

Multi-gateway payment processing with provider-agnostic routing. Double-entry ledgers with derived balances. Sub-merchant settlement under platform models. Reconciliation against provider settlement reports. On-chain payment handling and wallet integration. Identity verification and onboarding flows. Automated payouts with failure and recredit handling.

Integrity checked continuously, not at year end

The practice that separates a money system we would sign off from one we would not is whether it verifies itself on a schedule.

Every ledger we build carries a scheduled job that proves the books balance. Entries sum to zero, derived balances match the sum of their movements, and no account has drifted. It runs continuously and it alerts on a discrepancy the same day rather than at close.

Alongside that we run standing audits on the areas where money systems actually break:

• Money loss surface. Every path by which value can enter or leave, checked for the case where one side commits and the other does not.
• Race conditions. Concurrent operations on the same balance, double submissions, retried jobs, and the window between a provider's response and your write.
• Authorisation surface. Every action that moves money or changes entitlement, checked for whether the actor was genuinely permitted to take it.
• Scale behaviour. What the system does when volume is ten times higher and the queue is behind.

These are written documents that get revisited, not a one-off review. The point is that money bugs are rarely found by tests written before anyone understood the failure mode.

What is specific to this sector

Idempotency is not optional. Retries, duplicate webhooks and double-clicked buttons all arrive. Keys derived from the operation rather than generated at call time are the difference between a duplicate being rejected and a customer being charged twice.

Nothing is ever updated in place. Corrections are new entries. A balance you can overwrite is a balance you cannot audit, and the first chargeback proves it.

The regulator is not the only rule-maker. Card scheme rules apply independently of your regulatory position, and they are enforced through your acquirer rather than through a regulator you can talk to.

Reconciliation is a designed feature. Your ledger and your provider will disagree for six structural reasons. A system that expects equality will alert constantly and be ignored within a fortnight.